[
https://issues.apache.org/jira/browse/OPENJPA-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671345#action_12671345
]
Albert Lee commented on OPENJPA-910:
------------------------------------
>> Rule 3: If the same key is specified at the same level, a error message is
>> generated.
Throwing an exception seems too harsh for the following reasons:
1) Rule 2 says: "All monikers for a key are treated as interchangeable for all
purpose.....", so we should treated all property instances the same.
2) Based on 1), one property can override other, even with different prefix, at
different levels. For consistency, this should work the same at the same level
3) If 2 instances of the SAME property is specified in the same level, openjpa
currently will take the last instance's value, so I lean toward keeping the
same behavior.
4) The argument against 3) is which instance of the multiple definitions will
be used and how will user know which one is picked deterministically by
openjpa. hence the proposed rule 3, thrown an exception. To address the
concern, a warning can be issued indicating the value accepted and used by
openjpa configuration would be sufficient.
Albert Lee.
> Allow multiple keys for the same property to be specified at different levels
> -----------------------------------------------------------------------------
>
> Key: OPENJPA-910
> URL: https://issues.apache.org/jira/browse/OPENJPA-910
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Affects Versions: 2.0.0-M1
> Reporter: Dianne Richards
> Priority: Minor
> Fix For: 2.0.0
>
>
> In OPENJPA-850, support was provided for some 2.0 spec properties. Some of
> these properties are equivalent to current openjpa properties, resulting in
> some properties supported by 2 different keys. As part of this enhancement,
> an exception is thrown if the same property is specified more than once with
> different keys. An issue has been raised related to this suggesting that one
> key could be specified at one level (such as the persistence.xml) but another
> key could be specified at another level (such as a system property), and that
> we should allow this. This was discussed among several people, with the
> resulting conclusion documented by Pinaki as follows:
> Rule 1: OpenJPA configurations can be specified at following levels (from
> lowest to highest)
> I have changed Mike's order to reflect how the code (perhaps) now uses
> precedence (changing such order may require hard tweaks)
> > 1. openjpa.xml (globals)
> > 5. java.lang.System.getProperties()
> > 2. persistence.xml (<properties></properties>)
> > 3. A map passed in to the call to createEntityManagerFactory()
> > 4. A map passed in to getEntityManager()
> Rule 2: Each property is identified by a key. A key must have one, but can
> have multiple monikers. For example, 'ConnectionDriver' property has two
> monikers 'openjpa.ConnectionDriverName' and 'javax.persistence.jdbc.driver'.
> All monikers for a key are treated as interchangeable for all purpose other
> than when a key appears in the returned list of EMF.getProperties() -- which
> is always the moniker whose corresponding value is 'in effect' in the
> configuration.
> Rule 3: If the same key is specified at the same level, a error message is
> generated.
> Rule 4: If the same key is specified at different levels, the higher level
> value overwrite the lower level value.
> INFO/TRACE message is printed if the values are overwritten or attempted to
> be overwritten respectively.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
