Community
Participate
Working Groups
EclipseLink does not complain if one specifies @Access(FIELD) on a property. @Entity @Access(AccessType.PROPERTY) public class Employee { private int empId; @Id @Access(AccessType.FIELD) public int getEmpId() { return empId; } public void setEmpId(int empId) { this.empId = empId; } } This is confusing, since the anotation is on the property, but EclipseLink is going to use field access for persistence. This is not permitted according to the spec, I have the 10/21/2008 version and am looking at footnote 8 on page 24. 'It is permitted (but redundant) to place Access(FIELD) on a persistent field whose class has field access type or Access(PROPERTY) on a persistent property whose class has property access type. It is not permitted to specify a field as Access(PROPERTY) or a property as Access(FIELD).' If the field name is instead '_empId' and does not match the property, then an NPE occurs and a NoSuchFieldException for 'empId'.
This also begs the question (to the JPA 2.0 spec committee), why is Access(FIELD) or Access(PROPERTY) even used for this situation? This is redundant info to specify the accessType, why not another annotation @Persistent for this case? Then there would not be any confusion and no chance to use the wrong accessType on a field or property. @Entity @Access(AccessType.PROPERTY) public class Employee { @Id @Persistent (instead of @Access(FIELD)) private int empId; public int getEmpId() { return empId; } public void setEmpId(int empId) { this.empId = empId; } }
There is a fairly long story behind this feature and in the end the result is what the spec lead decided it should be and we are all living with it. However, that doesn't mean that we can't propose something again. Having said that, I wold say the annotation being the same for the field/property as the class is a good thing since it associates the reader with the same "access" aspect that it is denoting. Having a different annotation, such as @Persistent, would make one wonder why you needed an *additional* annotation to indicate something that already has an annotation. The question, then, ends up being "Why do you need to actually include the access mode when it is obvious from the context?" and the answer, I think, is so that you can't leave it empty when you do specify it for the class. The trade-off, then, is whether having to specify something that is redundant is worse than being allowed to annotate something that is incomplete.
It also occurred to me that this makes the definition the same in the orm.xml where you don't have context. There you *have* to specify field/property.
Targetting for 2.0 as this is the release where will be be revisiting Specification-related issues.
Same problem as bug 260296, wont you have a backwards compatibility issue if you wait to fix this in 2.0? The Dali team has been wondering if EclipseLink1.1 will continue to be supported in the future given the chance that the spec could change in such a way that you cannot help but break backwards compatibility. private int empId; @Id @Access(FIELD) public int getEmpId() { return empId; } What exactly does this mean, is EclipseLink going to use the empId field for persistence in 1.1 and then in 2.0 it is going to throw an error or ignore the @Access(FIELD) and just use the property for persistence?
At present the JPA metadata processor will ignore any @Access annotations in the class that do not match the place they are stored (i.e. FIELD on property or PROPERTY on a field. Only the ones that match and differ from the the @Access on the class will be considered. Note: It will throw an exception for duplicate mappings. I am deferring this to Future for now and will revisit it if it becomes a bigger deal to the user community. I strongly believe however that Dali should do as much as possible to help users avoid inconsistent annotation/XML configurations that will lead to annotations being ignored.
Changing the priority of the bugs that have been recently triaged to future. Targetting them to P2 will differentiate them from the P3s that have been triaged into future earlier.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
