Community
Participate
Working Groups
Currently System Properties are only applied if a persistence.xml property is not present. Usually it is considered that a system property is more specific than an application property so a system property would be a valid override for an application property; in this case properties from the persistence.xml file.
'not sure I agree. We should discuss.
Setting target. We should discuss this prior to deciding how to address this issue.
From an administrative and remote diagnostic perspective, I agree with Gordon Yorke on this front. For instance - the logging, and even specifying classes to disable cache for - if we have the ability to tell a customer to set a JVM property to increase logging, or disable caching for a specific class that we've found a problem with then we don't have to tell them to deploy a whole new application that we would have to build for them in order to update the persistence.xml. In general, in the JEE world the application developer can define settings, at deploy time (which would include JVM properties) the role of the deployer would mean they can decide to override or map specific resources - an example of this is EJB JNDI names, or mapping JDBC JNDI references to alternative data sources. As I understand it from the email in the user group, the following areas allow properties to be set: 1. persistence.xml 2. passed properties 3. System properties I would expect number 1. above to be the least important in terms of overriding. A JEE administrator would expect this, and it is a valuable way to customise settings that are specific to an environment over the top of the built application. Without this, you're stuck with whatever the developer/builder has defined and are powerless without a new application build. Kind Regards Nathan
Deferring to next major release.
Missed 2.5.0. Deferring.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
