The old deprecated databinding classes, e.g., org.eclipse.jface.databinding.swt.WidgetProperties, have been removed in 2022-12 (they have been replaced by org.eclipse.jface.databinding.swt.typed.WidgetProperties). Is RAP planning to provide a org.eclipse.jface.databinding.swt.typed package.

Otherwise, we would not be able to do single sourcing with databinding.

thanks in advance Lorenzo

If a Feature includes a Plugin, it usually includes it with a specific name and the version that was in the TP when the feature was build. This prevents consumers from using a slf4j bundle with different symbolic-name or different version in their TP or product.

This is part of https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/588

Copy of Bugzilla bug 579790

Example project showing the issue: example.redirect.zip (@mknauer: added target definition, launch configuration, modified dependencies)

When trying to redirect from an HTTP filter (extension org.eclipse.equinox.http.registry.filters), it fails with the following details:

Error: SyntaxError: Unexpected end of JSON input

  Stack: SyntaxError: Unexpected end of JSON input
    at JSON.parse ()
    at Object._handleSuccess (http://vm-uablochberg2:8080/rwt-resources/3180/rap-client.js:230:3602)
    at rwt.remote.Request._success (http://vm-uablochberg2:8080/rwt-resources/3180/rap-client.js:98:925)
    at rwt.remote.Request._onReadyStateChange (http://vm-uablochberg2:8080/rwt-resources/3180/rap-client.js:98:1596)
    at XMLHttpRequest. (http://vm-uablochberg2:8080/rwt-resources/3180/rap-client.js:7:219)
  Debug: off
  Request: {"head":{"requestCounter":3},"operations":[["notify","w6","FocusOut",{}],["set","w2",{"activeControl":"w2"}],["set","w1",{"cursorLocation":[394,277],"focusControl":"w2"}]]}

In the attached example project, there are four different methods for redirecting. But when called in the filter handler, even the JSON redirect does not work.

Is there some other way to make the redirect work from filter code (because this is needed for openID connect authentication)?

It would be best if HttpServletResponse.sendRedirect() would work in any circumstance.

Since Chrome 105 (same with Edge 105), as soon as a horizontal scrollbar appears, the UI assigns clicks to the scrollbar not only for the place where the scrollbar actually is present, but also for an area of about the same size below. I've included an example below. We can always reproduce it with the ScrolledForm of a FormPage.

In this screenshot, all the yellow area is actually handling the scrollbar. I only have a small area at the bottom of the pages where I can switch to one of the other pages.

Info:

• Tested with Eclipse RAP 3.21 (and 3.19)
• The problem didn't occur before Chrome 105 (we tested it against 104).
• We use the 'business' theme (maybe the problem doesn't occur with the default theme?)

Here an example how we can reproduce the problem with as little code as possible:

Editor Input

package test;

import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.ui.IEditorInput;
import org.eclipse.ui.IPersistableElement;

public class TestEditorInput implements IEditorInput {

    @Override
    public String getName() {
        return "title"; //$NON-NLS-1$
    }

    @Override
    public boolean equals(Object obj) {
        if (obj instanceof TestEditorInput) {
            return true;
        }
        return false;
    }

    @Override
    public <T> T getAdapter(Class<T> adapter) {
        return null;
    }

    @Override
    public boolean exists() {
        return false;
    }

    @Override
    public ImageDescriptor getImageDescriptor() {
        return null;
    }

    @Override
    public IPersistableElement getPersistable() {
        return null;
    }

    @Override
    public String getToolTipText() {
        return getName();
    }
}

Editor

package test;

import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.ui.PartInitException;
import org.eclipse.ui.forms.editor.FormEditor;

public class TestEditor extends FormEditor {

    public static final String ID = TestEditor.class.getName();

    @Override
    protected void addPages() {
        try {
            addPage(new TestPage(this));
            addPage(new TestPage(this));
            addPage(new TestPage(this));
            addPage(new TestPage(this));
            addPage(new TestPage(this));
        } catch (PartInitException e) {
            // ignore for this test
        }
    }

    @Override
    public void doSave(IProgressMonitor monitor) {
        throw new RuntimeException("The method doSave is not yet implemented for class EditorPart"); //$NON-NLS-1$
    }

    @Override
    public void doSaveAs() {
        throw new RuntimeException("The method doSaveAs is not yet implemented for class EditorPart"); //$NON-NLS-1$
    }

    @Override
    public boolean isSaveAsAllowed() {
        return false;
    }
}

Page

package test;

import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Label;
import org.eclipse.ui.forms.IManagedForm;
import org.eclipse.ui.forms.editor.FormEditor;
import org.eclipse.ui.forms.editor.FormPage;
import org.eclipse.ui.forms.widgets.ScrolledForm;

public class TestPage extends FormPage {

    private static final String ID = TestPage.class.getName();

    public TestPage(FormEditor editor) {
        super(editor, ID, "Title"); //$NON-NLS-1$
    }

    @Override
    protected void createFormContent(IManagedForm managedForm) {
        ScrolledForm form = managedForm.getForm();

        Composite body = form.getBody();
        body.setLayout(new GridLayout());

        Label label = new Label(body, SWT.NONE);
        label.setLayoutData(new GridData(6000, -1)); // almost guarantees a horizontal scroll bar
        label.setText("label"); //$NON-NLS-1$
    }
}

Right now, one can't set focus on columns that have false value for the visible variable on the grid.

    Display display = new Display ();
    Shell shell = new Shell(display);
    shell.setLayout(new FillLayout());

    Grid grid = new Grid(shell, SWT.BORDER | SWT.V_SCROLL | SWT.H_SCROLL);
    grid.setCellSelectionEnabled(true);
    grid.setHeaderVisible(true);
    GridColumn column = new GridColumn(grid, SWT.NONE);
    column.setText("Column 1");
    column.setWidth(100);
    GridColumn column2 = new GridColumn(grid, SWT.NONE);
    column2.setText("Column 2");
    column2.setWidth(100);
    GridColumn column3 = new GridColumn(grid, SWT.NONE);
    column3.setText("Column 3");
    column3.setWidth(100);
    column3.setVisible(false);

    GridItem item1 = new GridItem(grid, SWT.NONE);
    item1.setText("Item");
    GridItem item2 = new GridItem(grid, SWT.NONE);
    item2.setText("Item2");

    shell.setSize(500, 500);
    shell.open();
    while (!shell.isDisposed()) {
        if (!display.readAndDispatch()) {
            display.sleep();
        }
    }
    display.dispose();

Column 3 called setVisible(false) and SWT error throws an exception when the focus is on the column 3.

I have a possibility to hide columns and if I set focus on one of them, server error message is displayed, and one need to restart the application. I would expect not to terminate the application if one focus on the column, which is not visible.

stacktrace.txt

The RAP RC1 contribution has unsigned content:

https://download.eclipse.org/rt/rap/3.22/RC1-20220831-0943/

All these unsigned artifacts should have PGP signatures, but those are not present as reported here:

https://download.eclipse.org/oomph/archive/reports-extra/rap-3.22-rc1/download.eclipse.org/rt/rap/3.22/RC1-20220831-0943/index.html

I also manually checked this:

https://download.eclipse.org/rt/rap/3.22/RC1-20220831-0943/artifacts.xml.xz

The org.apache.commons.commons-io bundle, which I noticed was unsigned from manually testing installs of 2022-09 RC1 RAP, looks like this:

    <artifact classifier='osgi.bundle' id='org.apache.commons.commons-io' version='2.11.0'>
      <properties size='5'>
        <property name='download.size' value='327135'/>
        <property name='artifact.size' value='327135'/>
        <property name='download.md5' value='3b4b7ccfaeceeac240b804839ee1a1ca'/>
        <property name='download.checksum.md5' value='3b4b7ccfaeceeac240b804839ee1a1ca'/>
        <property name='download.checksum.sha-256' value='961b2f6d87dbacc5d54abf45ab7a6e2495f89b75598962d8c723cea9bc210908'/>
      </properties>
    </artifact>

But it looks like this in the platform's 4.25 I-Builds:

    <artifact classifier="osgi.bundle" id="org.apache.commons.commons-io" version="2.11.0">
      <properties size="12">
        <property name="maven-groupId" value="commons-io"/>
        <property name="maven-artifactId" value="commons-io"/>
        <property name="maven-version" value="2.11.0"/>
        <property name="maven-repository" value="eclipse.maven.central.mirror"/>
        <property name="maven-type" value="jar"/>
        <property name="download.size" value="327135"/>
        <property name="artifact.size" value="327135"/>
        <property name="download.md5" value="3b4b7ccfaeceeac240b804839ee1a1ca"/>
        <property name="download.checksum.md5" value="3b4b7ccfaeceeac240b804839ee1a1ca"/>
        <property name="download.checksum.sha-256" value="961b2f6d87dbacc5d54abf45ab7a6e2495f89b75598962d8c723cea9bc210908"/>
        <property name="pgp.signatures" value="-----BEGIN PGP SIGNATURE-----&#10;&#10;iQIzBAABCAAdFiEEnjBEBxt1jry35FZzcA5PObwFNksFAmMSLn0ACgkQcA5PObwF&#10;NksmBw/9GJFNIuqhHOQXz+I5ekcosGTOfw1Bcn2g3B7en5KjVToJYdkywNab1Dbh&#10;DZEzGK5daGZzD5075wa3jx3AmIBN5CJnj8rB1wLgWM4ZMi9VpyDv2mQqORB+RmOr&#10;gZDI/2ovqc9eosZ83/5TaihLL4Hzu95zwwObfPu0OtXexviIGCdkiBKtH+WiQbDV&#10;BVbOj7C6c8GmFTtlgF2zU8UvtVBql2BPzBRhnKSN0DuqjpFXcmM8HZJtpQ1C1i1Z&#10;m4/JlWy9YUvq9ljkK4As57zDePvfeqxng04EL7eGk6KEu2xsDZHgxPYD0bmMbaKn&#10;16CbCFOpVjhhVdhF2wUtGEHmryhZv2hCVg9VEvzxPmjadrVJqdi6CwRDI2xgLxd5&#10;XPUwNlTeI0flPcTUsUOCovx7w/enEC8orYcgEBvZkOxulmm084AhkA2pMSGX6XqS&#10;e5kxCiyiDt1SxaYQ8Qdr7BqFFlICOLu20ncyeROMt3FlsrbhgwS/Du8G1L+Sn5c1&#10;TM4s6EHPotKJmGHgC9vgUwVQ/DPLb0pKcvYVwyfgpOKl5lJvYhWS/sVzcqKvcINU&#10;3GqQLR4PYPcZKXrcKOYgVXobvLEqOeW8IJFAs9B3n9eXVt/Soo1TUZYaQs5Xutb0&#10;3IJxlvyvL4f/KjZa2jGCybhIDj4rODJzNK5h98deJUguXp2Ev3c=&#10;=JH5R&#10;-----END PGP SIGNATURE-----&#10;"/>
        <property name="pgp.publicKeys" value="-----BEGIN PGP PUBLIC KEY BLOCK-----&#10;&#10;mQINBFhaXO0BEAC8WCdwrJNF/W+C8m9FYwAhEvKBvQ7xmoGYZqgcYe2ntT8udvgZ&#10;k+dRwZJnu1VI3a8feOLrAmeNI2MxPP0+l2kGeC55c10duXPzLvW9oHONm39FZpCM&#10;X1m66TYkUBeu/DIttNf5l0nv54dmm4VAWjutnVmlKGf5MVmmAH4mrkmgs7UTyQRK&#10;JKJ8B7tAt6CI1tXq2ULjzUpz9iyD1IkWal4K2gYfooSuGLayNY+SCdcT9uZkpS4B&#10;rnHy2QeJqPSnJv+5G1SkX1fzavWelrf72vx+su8L8QzUa6JtGJatFbAHzEdXGJ98&#10;JnK7TAQvR3hCyzj+TnVCY1hiRO6B+4zI3j/vSJVdc5wmLejvfZRqhiaQ8Vr4xDbu&#10;w7/i+raAKwr//zVGAqp/zN6zQmyoLks+cfuI4yqHuXKGaNs5RapKCxfukC/TRB2e&#10;fLhqCpXAbRQ8a+R+0CCBP2WYDYNQoh4FnwuqtZefnm8NVKW+2we5y3llIrXV5PQb&#10;FFN5WOLuNvO/JOtRQSjNd4WYttwNCDP7ATpRK6ixz7qveztGNhuiCRx01HbZ2uUE&#10;DKV0DW8mWRjALl9/akMRcdIeTayKHDVjeNq5amnWT0vZ2F422BJW6sQryTs/NIBK&#10;XGoVVZeXms3fzL9IpztcVFZTuwmk5kk1FXXaBDMwVHlR5hC5gIuLIfLVEwARAQAB&#10;tDpFY2xpcHNlIFBsYXRmb3JtIFByb2plY3QgPHBsYXRmb3JtLXJlbGVuZy1kZXZA&#10;ZWNsaXBzZS5vcmc+iQI9BBMBCAAnAhsvBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheA&#10;BQJhuzR+BQkSxtkRAAoJELbTq5vMZBKCntUP/i+waQ1AAKEMBuwuP9KbAKNLyTFa&#10;Dl5cbwIcehAne5u7x3CfqYxc2NBCjM20akmYVnTYtvAriLKq9HcycYl98mxfWNOb&#10;/UtO2d04cBWqRn5U9TW0QbXrA3/kScmKzf8qWr2m6DLgl3ZVewapoP9iNYOVeWRB&#10;iI7ap+yLJwlRp0YxPjpgkSeV5+ghFpUG3ppqAIlB5QaNadbG9xIoqcs0x4gdyrUS&#10;uPFX42p6y+JIM31eDW4hKcyo29C8xg4oMQsmL6fZAASP+IXboqjaK/QijA2etVsq&#10;vyv8A+FAzZlV9zEx9EY6aJvIjABDV0IUrbfbmyUckM/sbsy7Wa13koiMIAUu8ylv&#10;HOXkblBqUPDeoZS1KXOpiRHoJ0+WalLWayiWSOiDdMeq2Le0EZvLhvK/No4TZWSl&#10;WEa3IZA/nKHeDI5Sv4NG4kcFyrrgJSphezgF3dU+EePeAtOYv3OWpLbgKbs2BTY3&#10;B7Y36aX6svrJD667bPkjj7EQumJSr6vtEB7YJF5WtXR3voviDACpm0+jJN7KQsmM&#10;X26z6J8VNOqzQvTekRZKr1lSSgECPdHZQaBfTM5ODiOGkVInR0LN9Tx1zriuQdoh&#10;vMlXF/EmuxzKi7TP9MfW6xB6/7gAIJDdEhJni5+Q14U5j6oOaXUzpcFEjg7xyBe7&#10;0/Inw3JlHfp/q2McuQINBFhaXPsBEAC3bR7f5euHbpIDDTuFYHPI0+S5X0DhuqcG&#10;BUL2HSFhWMwIlfsAaO+pt7GyfXLUkTmzugwmwO+sOW2QmwEZQcK2z3BrcjytZoph&#10;Z9AUajbAjnadSH6UXCMmfExVVnaYSfl/+Uub42szQE/r3gCRIz6M6clVVAjpFv4G&#10;/mumfQUV/XzLoUEYXTgwTokFJ97R+hDbHvBEBrUT8M6zHP5DhN3EBug3qb6wZVOa&#10;/+HEX3M+7k4jVT/ppNumw0acg0DDoSNQ13VsRV6sV0XE4zr3Zfs84f8xCgXpEMs4&#10;U6DZGqs3iJVVtbRf0oL0fgcxNgRrmbCrBfbXYfrS4u+fJ0vB+Wrflv9eNA3i6TtV&#10;L6uYpZy9uO2B1olKVzfEhsgB3QrULB4jVHZjIXGe4ILn45ndMtAeY4M91wyobgG9&#10;9Xl+1vPHrxV0+2zRP66J3puyxiKE2B7gd7hib54CB3lYyrG1S+K1kZGCI1IFKCnq&#10;mTJXY0tKoLAASS3vtDcknXenzR5RVSpWTDuxtusekfL0Bw8pCBoz9L4Hex8Q1j//&#10;D5CZlqcg1NKFfmBZ7ta9PTuJcpOsz/LaPG/0VHYt/QAv5o4eeZESl7iZyM4/0NFh&#10;2s/rq0R8Z9yVSSkIvvO8d8XGZ65NTm3T4NFuEihn+AEm+zg4KiGdYBEZvs8QQoW9&#10;e1+MMN8xnwARAQABiQREBBgBCAAPAhsCBQJhuzR9BQkSxtkCAinBXSAEGQEIAAYF&#10;AlhaXPsACgkQcA5PObwFNkunSw//SRR1tGS1pDj2jonLpR0wPilCphS6ANv895yv&#10;lg6rHG4nKi4hQ0JzZxhGCwkgxEkRaKiyLfEiTihETkF161AqLPhyvE8LuQ1AG+A+&#10;tUnR8/T3gKE8t/m2/UtScZwN1QEQVc/uG7MTrbZ2ngXfH65k3fzhjy95AnJHAswu&#10;2vic1hzDi77HlQpN0O3adJuU/jfdu1RxNE0MRt8MFEjsTFwSBVm6lDxgcZV+qjRL&#10;GQznTyLF5/AyCI7Z4z9xHZPKFq1eHzqevifNiqfb8KX22sHKOSdnVBzBq/UxbT5j&#10;IbNSRhD91FjtZD7Z6wi3POsB/9RWZBldCov4ZEajmxFzxpx4RAqYOSIkEor9ZtRG&#10;bZuWvTie4vFIur7Tf543mE6nxKcggExNp4MTyOd1scMc9oyczH561OTdHOCYEyoC&#10;wpG9N2Hb1/MDnWSiHKG451CvdrE5FHcPZKjp/nHUcRw/WQC3bgj6ScAay64EKC5S&#10;9tW+Wp85Oyyvj+M7lBzOxp19nESpfC++fzBAQPMxtD8EvrZTxqFSJxMOH9bhzB8+&#10;MFt08tmYb5SwoYi4C8JJ+wZgNetJKK+j07fvyMUChH/SbkCVszMiiSEjHA2Kk0LM&#10;VYKS/OLJU7i7tZXVaJ078QEeTDy5hSzsutd+orlFkR9+mgr1HUh0UgYlofTfEi7b&#10;LDeSr0cJELbTq5vMZBKCicIP/irazYBVKw0SluhHtjzRcs5WIdH5bVPsEE87+iUc&#10;4daONWdVIhLdokxtOWlrEmZFLKqq9Z8fzvlf5LAQMOBkMAkl0z2ej4KG7zrjWyqD&#10;gysEI2WBlqTAFSeL+89Kc9BzJE9heYW8EfpXbNfOnKnAYWsbhcomSxVQ/jBIuyLB&#10;g/0gYKpBNx8HC6v9xNH0Ja+wM/7w3JC1aIwMYJn1yF2ykUYS+BoTCU7TA8r43pHg&#10;4I4Fz+Y2P5RLk+RJI4kJezDNiJOpIcr/nKTPxMGUzMtWlGyAJ7LkyOZCtQXhtXwa&#10;T8grjtHzlwlGrpgDRtf7wWjzEWeaQSegTFM9Mid+09kCp0PkJvveg8wJCuoVboNO&#10;to0O5rQsUczjXxiWkXYlHGeQL4rWc1zP7F1n4DEwDbVZC7jOn/80l3x4LcKuhc86&#10;gP4L5HKbdjn5GcQ03RVLl1WVTQCdpr0+am28hl9XpyHdlWwSEmqqoUnjGv5B8RCl&#10;ocBRS4ECPPZCVSBlyK8eDgRww9Fu1EFq4xkq5fGj4YUOAIm756iW41NQ3VnPYbom&#10;/J27iFFN8+h92CSbKAqhmRwQh+GGo0eGCXmPHyQ/KCHTvnTZCFBUvabm3rVNFaDO&#10;+RvmwPwNCRz0DYzGpaeMOGo4nMMGbzdhgfJ/X5Ed1/Mqz8egHhGIO94ebKEN5ZtJ&#10;jAOK&#10;=EmXb&#10;-----END PGP PUBLIC KEY BLOCK-----&#10;"/>
      </properties>
    </artifact

From the sha-256, I can see it's the same artifact.

What version of Tycho is being used for the builds? You must use a newer version such as 2.7.3 or 2.7.5. If you are pulling directly from Maven yourself, you must PGP sign it...

Looks like org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRenderer.updateVisibility(MenuManager, MMenuElement, ExpressionContext) has not been upgraded when imperative expressions were introduced.

Hi,

this method seems to be missing. The JavaDoc and method from SWT:

/**
 * Sets the receiver's tool tip text to the argument, which
 * may be null indicating that the default tool tip for the
 * control will be shown. For a menu item that has a default
 * tool tip, setting
 * the tool tip text to an empty string replaces the default,
 * causing no tool tip text to be shown.
 * <p>
 * The mnemonic indicator (character '&amp;') is not displayed in a tool tip.
 * To display a single '&amp;' in the tool tip, the character '&amp;' can be
 * escaped by doubling it in the string.
 * </p>
 * <p>
 * NOTE: Tooltips are currently not shown for top-level menu items in the
 * {@link Shell#setMenuBar(Menu) shell menubar} on Windows, Mac, and Ubuntu Unity desktop.
 * </p>
 * <p>
 * NOTE: This operation is a hint and behavior is platform specific, on Windows
 * for CJK-style mnemonics of the form " (&amp;C)" at the end of the tooltip text
 * are not shown in tooltip.
 * </p>
 * @param toolTip the new tool tip text (or null)
 *
 * @exception SWTException <ul>
 *    <li>ERROR_WIDGET_DISPOSED - if the receiver has been disposed</li>
 *    <li>ERROR_THREAD_INVALID_ACCESS - if not called from the thread that created the receiver</li>
 * </ul>
 *
 * @since 3.104
 */
public void setToolTipText (String toolTip) {
	checkWidget();
	if (toolTip != null && (toolTip.trim().length() == 0 || toolTip.equals (toolTipText))) return;

	this.parent.getShell().setToolTipText (handle, (toolTipText = toolTip));
}

In RWT the handle is obviously missing.

Would be nice if that could be implemented. If someone would suggest a fix I could try to make a PR.

Thanks, Bye Peter

Hello,

We have upgraded our RAP version in our WAR file from 2.1 to 3.10 and deployed it on Jboss7. We have observed that:

1. mouse events are not working on table header
2. Combo box multiple character search stopped working . i.e. Instead of entering one character that takes you to the first instance of a word... if you enter two characters... you get the closer match

These features were working fine with RAP 2.1

From RAP community, I get to know that mouse events are NOT triggered in Table/Tree header. This change has been introduced here: https://git.eclipse.org/r/c/rap/org.eclipse.rap/+/22050/

Could you please let us know when you are planning to fix this issue. This is a bit urgent as customer go live is blocked.

Here is the code snippets that we have used. It is a high level information and I am hopeful that it will help you to understand the situation.

We have class HeaderSortListener that implements MouseListener

public class HeaderSortListener implements MouseListener {
    /**
     * {@inheritdoc}
     */
    public void mouseDoubleClick(MouseEvent pE)
    {
        // TODO Auto-generated method stub
    }

    /**
     * {@inheritdoc}
     */
    public void mouseDown(MouseEvent pE)
    {
        // TODO Auto-generated method stub
    }

    /**
     * {@inheritdoc}
     */
    public void mouseUp(MouseEvent pE)
    {
// This function has business logic that perform the sort. Ideally this function should get called when table header is clicked.
// Observation : This function was getting called when we were using RAP 2.1. Once we upgraded RAP version to RAP 3.10 , This function is no more called on table header click.
    }
}

We have a initialize() method in a class from where we are registering header sort listener.

public class CustomMassTable  extends Composite
    implements TraverseListener, DragDetectListener, ModifyListener, IDoubleClickListener, DropTargetListener,
    IFilterListener, IErrorListener, KeyListener, IModifiable, IValidable
{
// Few instance variable and other stuff
private MouseListener headerSortListener;
private Table table;
private CheckboxTableViewer tableViewer;
public CustomMassTable(Composite pParent, int pStyle, boolean pMultiSelection, boolean pCheckLine, boolean headerVisible,
        Class<?> pObjectClass)
    {
        super(pParent, pStyle | SWT.NO_FOCUS);
        // Some initiation 
        initialize(descriptor);

    }

private void initialize(CustomMassTableDescriptor pDescriptor)
    {
// Some processing and layout build
table = new Table(middleComposite, tableStyleFlag);
tableViewer = new CheckboxTableViewer(table);
headerSortListener = new HeaderSortListener(this, sortIndex);
table.addMouseListener(columnSortListener); // This is responsible for registering the mouse event on table header and 
                                                                          //should call mouseup(MouseEvent pE)
}

}

In many web applications it is possible to unveil the password entered into a password text field by an "eye" icon on the right side: RAP is still missing this functionality. It would be nice, if in the future, RAP would support such an "eye" icon as well.

Web UI for NetXMS (open source monitoring platform) is built on RAP. References: Source code - https://github.com/netxms/netxms Product home page - https://netxms.org

As far as I understand, the deployment process of the release artefacts to Maven Central is still a separate (internal) process. It seems that nowadays it's possible to deploy directly to Maven Central using Tycho.

Since I only consume the RWT dependencies from Maven Central in my project, I can offer to have a look into how to improve this process, so it could integrate better into the regular release process. In this case it would be nice if you could share some insights in how it is currently done and where it should probably be integrated (e.g. in the RAP builds?).

Best regards, Ben

See also: #63

I've observed this issue for a few years now back when I started to work with RAP-3.1 and it still is present in RAP-3.22. From time to time and for no appearant reason clients stop responding to browser-resize events, while everything else continues to work just fine.

Typically when resizing the browser window, the client accumulates changes and periodically pushes those values to the server (setBounds, notifyResize). At first I had doubts whether this could be an issue with application-code (some resize-listeners missing), but than I noticed even a minimal example with only an empty entrypoint causes those setbounds/notify-messages to be sent over. For a client in degenerated state however, no network messages are sent to the server on resize - and while other events/etc work just fine, also other events don't cause a resize (so this rules out those resize-messages are just stuck somewhere and don't cause a flush).

I tried to debug the issue further, but now I am a bit stuck:

• in _dispatchEvent (Internal event dispatch method), I see evt._valueType with "windowresize", so the browser seems to trigger the event:

• and later recompute also detects the width changes:

after which it flushes the GlobalQueues. but no network request is issued by this.

In contrast, on a working client I get additional related events after a browser resize, like the changeWidth event shzown in the screenshot below. This changewidth-event is completly missing in the dysfunctional state:

I would be really grateful for hints where to debug / search further. The fact that this seems to happen seldom and quite random makes it hard to dig deeper...

Update: I wasn't sure whether this happens only on Firefox, but in a ticket from 2019 I just found the note "mostly happens when using google chrome". so the issue doesn't seem to be browser-specific.

After previously upgrading to RAP 3.20, we occasionally see this exception in production. Unfortunately we haven't found a way to deterministically reproduce it.

Any Suggestions? Thanks!

2022-11-21T22:28:10.383146347Z java.util.ConcurrentModificationException
2022-11-21T22:28:10.383157823Z  at java.base/java.util.ArrayList$Itr.checkForComodification(Unknown Source)
2022-11-21T22:28:10.383167628Z  at java.base/java.util.ArrayList$Itr.next(Unknown Source)
2022-11-21T22:28:10.383175730Z  at org.eclipse.rap.json.JsonArray$1.next(JsonArray.java:420)
2022-11-21T22:28:10.383184205Z  at org.eclipse.rap.json.JsonArray$1.next(JsonArray.java:1)
2022-11-21T22:28:10.383192454Z  at org.eclipse.rap.json.JsonWriter.writeArray(JsonWriter.java:120)
2022-11-21T22:28:10.383200133Z  at org.eclipse.rap.json.JsonArray.write(JsonArray.java:431)
2022-11-21T22:28:10.383207462Z  at org.eclipse.rap.json.JsonWriter.writeObject(JsonWriter.java:95)
2022-11-21T22:28:10.383214666Z  at org.eclipse.rap.json.JsonObject.write(JsonObject.java:593)
2022-11-21T22:28:10.383222008Z  at org.eclipse.rap.json.JsonWriter.writeArray(JsonWriter.java:124)
2022-11-21T22:28:10.383229769Z  at org.eclipse.rap.json.JsonArray.write(JsonArray.java:431)
2022-11-21T22:28:10.383238040Z  at org.eclipse.rap.json.JsonWriter.writeArray(JsonWriter.java:124)
2022-11-21T22:28:10.383246024Z  at org.eclipse.rap.json.JsonArray.write(JsonArray.java:431)
2022-11-21T22:28:10.383253769Z  at org.eclipse.rap.json.JsonWriter.writeObject(JsonWriter.java:95)
2022-11-21T22:28:10.383261714Z  at org.eclipse.rap.json.JsonObject.write(JsonObject.java:593)
2022-11-21T22:28:10.383269856Z  at org.eclipse.rap.json.JsonValue.writeTo(JsonValue.java:396)
2022-11-21T22:28:10.383277419Z  at org.eclipse.rap.rwt.internal.service.LifeCycleServiceHandler.writeResponseMessage(LifeCycleServiceHandler.java:189)
2022-11-21T22:28:10.383284946Z  at org.eclipse.rap.rwt.internal.service.LifeCycleServiceHandler.processUIRequest(LifeCycleServiceHandler.java:101)
2022-11-21T22:28:10.383305960Z  at org.eclipse.rap.rwt.internal.service.LifeCycleServiceHandler.synchronizedService(LifeCycleServiceHandler.java:75)
2022-11-21T22:28:10.383316337Z  at org.eclipse.rap.rwt.internal.service.LifeCycleServiceHandler.service(LifeCycleServiceHandler.java:66)
2022-11-21T22:28:10.383324481Z  at org.eclipse.rap.rwt.engine.RWTServlet.handleValidRequest(RWTServlet.java:135)
2022-11-21T22:28:10.383332839Z  at org.eclipse.rap.rwt.engine.RWTServlet.handleRequest(RWTServlet.java:117)
2022-11-21T22:28:10.383340918Z  at org.eclipse.rap.rwt.engine.RWTServlet.doPost(RWTServlet.java:107)
2022-11-21T22:28:10.383348862Z  at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
2022-11-21T22:28:10.383360164Z  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
2022-11-21T22:28:10.383367739Z  at org.eclipse.rap.rwt.osgi.internal.CutOffContextPathWrapper.service(CutOffContextPathWrapper.java:106)
2022-11-21T22:28:10.383376943Z  at org.eclipse.equinox.http.servlet.internal.HttpServiceRuntimeImpl$LegacyServlet.service(HttpServiceRuntimeImpl.java:1457)
2022-11-21T22:28:10.383385782Z  at org.eclipse.equinox.http.servlet.internal.registration.EndpointRegistration.service(EndpointRegistration.java:159)
2022-11-21T22:28:10.383394146Z  at org.eclipse.equinox.http.servlet.internal.servlet.ResponseStateHandler.processRequest(ResponseStateHandler.java:67)
2022-11-21T22:28:10.383402374Z  at org.eclipse.equinox.http.servlet.internal.context.DispatchTargets.doDispatch(DispatchTargets.java:118)
2022-11-21T22:28:10.383410801Z  at org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.dispatch(ProxyServlet.java:147)
2022-11-21T22:28:10.383419049Z  at org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.preprocess(ProxyServlet.java:115)
2022-11-21T22:28:10.383426890Z  at org.eclipse.equinox.http.servlet.internal.servlet.ProxyServlet.service(ProxyServlet.java:104)
2022-11-21T22:28:10.383434324Z  at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)

State written through MPart.getPersistedState().putIfAbsent() is not present in the saved model file. This happens because invoction of the @PersistState annotated methods happens after the model file has been written.

This is the stack of writing the model:

E4Application.saveModel() line: 193	
E4EntryPointFactory.createWorkbench() line: 85	
E4EntryPointFactory$1.createUI() line: 45	
RWTLifeCycle.createUI() line: 177	
RWTLifeCycle$UIThreadController.run() line: 290	
UIThread(Thread).run() line: 834

This is the stack of invocation of the @PersistState annotated methods:

PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.safeRemoveGui(MUIElement) line: 865	
PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.safeRemoveGui(MUIElement) line: 858	
PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.safeRemoveGui(MUIElement) line: 865	
PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.safeRemoveGui(MUIElement) line: 865	
PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.safeRemoveGui(MUIElement) line: 865	
PartRenderingEngine$3.run() line: 828	
SafeRunner.run(ISafeRunnable) line: 45	
PartRenderingEngine.removeGui(MUIElement) line: 813	
PartRenderingEngine.stop() line: 1195	
E4Application$1(E4Workbench).close() line: 191	
E4EntryPointFactory.createWorkbench() line: 86	
E4EntryPointFactory$1.createUI() line: 45	
RWTLifeCycle.createUI() line: 177	
RWTLifeCycle$UIThreadController.run() line: 290	
UIThread(Thread).run() line: 834	

If you compare the stacktraces, you will find that writing the model happens in E4EntryPointFactory.createWorkbench() line: 85 but invocation of the @PersistState annotated methods happens afterwards, in E4EntryPointFactory.createWorkbench() line: 86

When using autoHeight / varialbe height grid rows, GridEditor Widgets are not properly positioned - but instead are positioned where they would belong with standard row height. My guess is, the problem originates from the height of the grid rows being computed client-side, but the GridEditor Widgets are layouted server-side.

public class BasicEntryPoint extends AbstractEntryPoint {

  protected void createContents(Composite parent) {
	parent.setLayout(null);
	
	Grid grid = new Grid(parent, SWT.BORDER | SWT.V_SCROLL | SWT.H_SCROLL);
	grid.setData(RWT.MARKUP_ENABLED, true);
	grid.setAutoHeight(true);
	grid.setBounds(100, 100, 500, 500);
	
	GridColumn actionCol = new GridColumn(grid,SWT.NONE);
	actionCol.setText("Action");
	actionCol.setMinimumWidth(200);
	
	GridColumn textCol = new GridColumn(grid,SWT.NONE);
	textCol.setText("Textcolumn");
	textCol.setWidth(200);
	
	generateItem(grid, "multi <br/> line");
	generateItem(grid, "single line");
  }
  
  void generateItem(Grid grid, String txt) {
	    GridItem item = new GridItem(grid,SWT.NONE);
	    item.setText(1, txt);

		Button b = new Button(grid, SWT.PUSH);
		b.setText("button");
		
		GridEditor editor = new GridEditor(grid);
		editor.minimumWidth = 150;
		editor.minimumHeight = 10;
		editor.setEditor(b, item, 0);
  }
}

Is it possible to instruct a DateTime Calendar control in RAP to NOT show the week numbers down the left side? In many cases these just clutter the display so would like to simplify the look and feel: