BeanItemContainer shows Items in reverse order in Table

What might I be doing wrong that I load a BeanItemContainer with objects such that the ‘name’ field is in order as I call the addItem(), but when the table comes up, it’s rendereed in reverse order?

Here’s how I create the container:

public class GroupViewContainer extends BeanItemContainer<GroupBean> implements Serializable {
	private static final long serialVersionUID = -163456573303929195L;

	public GroupViewContainer(final EsfVaadinApplication vaadinApp) throws InstantiationException, IllegalAccessException {
		super(GroupBean.class);

		List<Group> groups = Group.GetPermGroupView(vaadinApp.getUser(),Group.INCLUDE.BOTH_ENABLED_AND_DISABLED);
		for( Group g : groups ) {
			addItem( new GroupBean(vaadinApp,g) );
		}
	}
}

Then my Table is just calling setContainerDataSource with my instance of the GroupViewContainer. I know I’m doing something wrong since I can add an ItemClickListener and get the click event for RIGHT CLICK, but my Property.ValueChangeListener does not seem to be invoked when I click on a row in the table. I suspect these are somehow related bugs to something I’ve done.

Any ideas would be helpful. I’m not even sure where to place my breakpoints to figure it out.

First make sure the iteration in which you insert the items goes in the correct order.
Then check that the table has no sorting activated.

Also, incorrect implementations of equals() and hashCode() in your beans could conceivably cause some strange behavior.

If these do not help, you could put breakpoints at the beginning and end of BeanItemContainer.filterAll() and see if the order of allItems is correct, and if the method somehow changes the order.

Is the table in the immediate mode? A table is an AbstractSelect, and its value (the item ID of the selected item, or a collection of those if in multiselect mode) is only communicated to the server if it is immediate or if some other immediate event takes place on the UI.

Thanks, Henri. I hate to have to admit it, but it was a bug in our equals method when we wrapped an existing class (more than a simple javabean) to be more suitable for use in vaadin tables/forms. We were inadvertently comparing the wrapped bean with the wrapper bean when we delegated to the wrapped bean’s equals method. But because our compareTo was correctly coded, we could sort the column and get the correct results. Sadly, we discovered this a bit ago, I just never updated the forum of our mistake.

	@Override
	public boolean equals(Object o) {
		return group.equals(o);
	}
	@Override
    public int hashCode() {
    	return group.hashCode();
    }
	public int compareTo(GroupBean g) {
		return group.compareTo(g.group);
	}

‘group’ is the wrapped object, and we delegated the wrapper to use the it’s equals/hashCode/compareTo, but the original equals shown above was passing ‘o’ along rather than it’s ‘o.group’ object. Ugh!