Richard Zowalla created OPENJPA-3006:
----------------------------------------
Summary: EntityManagerFactory.getProperties() is not usable as
configuration input
Key: OPENJPA-3006
URL: https://issues.apache.org/jira/browse/OPENJPA-3006
Project: OpenJPA
Issue Type: Bug
Components: jpa
Reporter: Richard Zowalla
EntityManagerFactory.getProperties() merges the EntityManager level defaults
(harvested from the Broker and FetchPlan) into the factory properties. Those
values are *user readable*: enums, live instances and unprefixed keys. The
resulting map cannot be fed back into
Persistence.createEntityManagerFactory(name, map), which is a pattern our own
tests use (TestSchemaGenDrop step 4 does new HashMap<>(emf.getProperties())).
Three distinct problems, all reproducible by creating an EntityManager and then
passing emf.getProperties() to createEntityManagerFactory:
1. Enumerated values. openjpa.AutoClear is reported as AutoClearType.DATASTORE,
while IntValue.setInternalObject requires a Number, giving "ParseException:
AutoClear: DATASTORE". Value.unalias compares alias names case sensitively, so
the string form DATASTORE would not match the alias datastore either. The same
applies to openjpa.DetachState, openjpa.ConnectionRetainMode and
openjpa.AutoDetach (an EnumSet).
2. Live instances. openjpa.EntityManagerFactory and openjpa.ManagedRuntime are
reported as the objects themselves rather than as their plugin strings.
3. Key collisions. The EntityManager contributes unprefixed keys, so the map
holds both FetchBatchSize and openjpa.FetchBatchSize, and
ProductDerivations.getConfigurationKey fails with "IllegalStateException: Found
multiple properties with different valid prefixes".
Today the failures are masked by accident:
EntityManagerFactoryImpl.getProperties() caches its result, so whether the
EntityManager level values are present at all depends on whether an
EntityManager was created before the first call.
TestPropertiesMethods.testEMFPropertyValueTypeIsPreserved passes because they
are present (it asserts openjpa.AutoClear is an AutoClearType), and
TestSchemaGenDrop passes because they are not. See OPENJPA-2982, where making
the merge deterministic exposed all of the above.
What needs deciding is the contract of the map. Either it stays a human
readable report, in which case the round trip should be documented as
unsupported and the tests should stop relying on it, or it becomes valid
configuration input, which means reporting config-safe values for prefixed
keys, dropping the unprefixed duplicates, and making Value/ProductDerivations
tolerant of enum values and prefix collisions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
