Community
Participate
Working Groups
In TopLink we can specify at an individual mapping level a get/set method pair that TopLink will use when interacting with the instances. These methods do not need to match any specific naming convection. In order to have our new ECLIPSELINK-ORM.XML XSD provide equivalent support we need to have this capability in all mappings. I believe the actual XML and annotations configuration should be pretty straight forward. Maybe something like: <basic name="value"> <access-methods get="getValue" set="setValue"/> </basic> @AccessMethods(get="getValue", set="setValue") If a user specifies or implies FIELD access then this would still cause TopLink to use the get/set methods for this specific mapping and our weaving would adapt for this. If the user has specified or implied PROPERTY access then this configuration is a way to override the method names that are assumed. I thought I would get the ball rolling on this one since it effect all mappings.
The prev. posting is a copy of Doug's e-mail message.
Changing default access type has been discussed in the JPA 2.0 expert group. My guess is there will be a spec defined element that will look something like <xsd:complexType name="access"> <xsd:annotation> <xsd:documentation> Specifies an access type that is different from the defaut. Can be applied at the entity level or at the property level. </xsd:documentation> </xsd:annotation> <xsd:attribute name="type" type="orm:access-type" use="required"/> </xsd:complexType> <xsd:simpleType name="access-type"> <xsd:annotation> <xsd:documentation> Access type for Entity and Entity properties. FIELD or PROPERTY </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:token"> <xsd:enumeration value="FIELD"/> <xsd:enumeration value="PROPERTY"/> </xsd:restriction> </xsd:simpleType> our EclipseLink "access" annotation should allow for get-method and set-method as well <xsd:complexType name="access"> <xsd:annotation> <xsd:documentation> Specifies an access type that is different from the defaut. Can be applied at the entity level or at the property level. </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="access-methods" type="orm:access-methods" minOccurs="0" maxOccurs="1"/> </xsd:sequence> <xsd:attribute name="type" type="orm:access-type" use="required"/> </xsd:complexType> <xsd:complexType name="access-methods"> <xsd:annotation> <xsd:documentation> Specifies an the getter and/or setter method for when PROPERTY access is used. </xsd:documentation> </xsd:annotation> <xsd:attribute name="get-method" type="xsd:string"/> <xsd:attribute name="set-method" type="xsd:string"/> </xsd:complexType>
Translating Gordon's schema defintion into an instance example I believe we have: JPA 2.0's access type @Access(AccessType.PROPERTY) <access type="PROPERTY"/> So, then in EclipseLink we want to build on this enabling the specification of get/set methods. We want the annotation solution to work well with JPA 2.0's: @Access(AccessType.PROPERTY) @AccessMethods(get="_getValue", set="_setValue") Note: Specifying @AccessMethods without @Access(PROPERTY) is equivalent. We need to decide what we want to do if @Access(FIELD) is specified and then the user specifies @AccessMethods as well? On the XML front we have two choices. We can build a solution extending what will be in JPA 2.0's ORM.XML so we look something like: <access type="PROPERTY"> <get-method name="_getValue"/> <set-method name="_setValue"/> </access> The challenge with this is we must also support the case where the customer has a standard JPA ORM.XML and is using the ECLIPSELINK-ORM.XML to extend that and want to specify that not covered by the standard XML. To address this better to follow the rule that annotation == element we should consider: <access type="PROPERTY"/> <access-methods get="_getValue" set="_setValue"/> I vote for this latter solution as it offers consistency with the above annotation approach and better enables the extension use case where <access-methods .../> only exists in the ECLIPSELINK-ORM.XML document.
The AccessMethods annotation will also require a name value, since it may not be possible to derive a property name from the get/set methods provided - for EclipseLink, bla() could be a valid get method. Another issue is that how EclipseLink determines the default access type will need to change slightly. Currently, if no accesstype is defined, EclipseLink will search methods for any persistence annotations. If it finds any, it uses property access, otherwise it defaults to field access. With @Access annotations allowed on fields/properties it has been proposed by Gordon that EclipseLink ignore any @Access annotated properties, such that it will choose property access if there are any properties annotated but do not have the @access annotation, otherwise it defaults to field access.
For the 1.0 release where we will not have any JPA 2.0 defined classes we should simply avoid the use of @Access/<access>. We should simply address the specification of user supplied get/set method names with @AccessMethods/<access-methods...>. When either of these exist within a mapping we can assume method attribute access and use the names supplied.
Created attachment 99773 [details] proposed patch
Created attachment 99950 [details] proposed fix to be checked in
fix checked in
The patch includes the following change to the eclipselink_orm_1_0.xsd: <xsd:complexType name="access-methods"> <xsd:annotation> <xsd:documentation> </xsd:documentation> </xsd:annotation> <xsd:attribute name="get-method" type="xsd:string" use="required"/> <xsd:attribute name="set-method" type="xsd:string" use="required"/> </xsd:complexType> This access-methods tag allows defining the get and set methods that EclipseLink will use for property access on a specific attribute. Both get and set methods must be specified when using this tag, and the get/set signatures must match the usual JPA property restrictions, but there are no restrictions on what the methods are named. An example would be: <basic name="firstName"> <column name="FIRST_NAME"/> <access-methods get-method="_getFirstName" set-method="_setFirstName"/> </basic> The above example will cause EclipseLink to use _getFirstName and _setFirstName to access firstName regardless of the access type defined elsewhere (explicit or defaults). This can only be defined through xml as there is no equivalent annotation.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
