Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Create/open programatically a JPA project 2. Create/open programatically an entity in it with the following code: package com.test.persistence; import javax.persistence.*; @Entity public class Entity1 { private long id; @Id public long getId() { return id; } public void setId(long id) { this.id = id; } } 3. Add ListChangeListener to the JavaPersistentType object corresponding to the entity 4. Somehow (through JDT or manually) remove the 'id' attribute of the entity More information: As a result the listener will catch more than one event objects in its itemsRemoved(...) method for one and the same event - removing the 'id' attribute. This behavior reproduces only if there is just one attribute in the entity. If there are two or more attributes in the entity, the listener catches only one event per removing. I'm not sure if the problem is related to the annotation type - notice that the entity is method annotated. I haven't tested it with field annotated entity. The problem is often, but not always reproducible.
I am not seeing this problem with the latest 2.1 code. I am unsure what build M20080911-1700 is, the 2.1 stream, 2.2 stream, or the 2.0 maintenance stream? A test case would also be helpful, even if it only fails some of the time.
I have a JUnit test that catches the problem, but it's related to many other things. I'll try to clean it up and provide it.
Please re-open with additional information or test case.
It appears that 'the error is correct' :). I still can observe the described behavior, but it's not a bug. Let's have an entity with just one attribute - id and let's say that this entity has a property access - the getter of the id is annotated. What happens when we subsequently remove methods and the field? Well, it depends on the order. If we first remove the getter method, we get an event that this attribute is removed. Then the entity remains with one field and with setter. Apparently, DALI assumes that we have an entity with field access and one (basic) attribute named id (which is correct), so we get an event that this attribute has been added. We are still going on with our removing of the id attribute. Now we are removing the id field and as a result we are getting one more event that this attribute has been removed. At the end we have removed the getter, setter and the field and we received three events - one for adding and two for removing the attribute. To avoid this effect we have to remove all the parts of the attribute at once or we have to remove them in order determined by the access of the entity - remove the annotated part last.
Yup, that sounds correct, and given our dependence on the JDT model events there's really no way around this. I'm not sure why it would really cause you problems, are these unit tests that are checking the events that are fired? If you are listening to our model you would have to listen to add and remove events so it really wouldn't matter if there are more of them than you expect. And to try and test that expectation would be difficult since you can't determine when you are going to get a JDT model events since those are sent asynchronously.
