rzo1 opened a new pull request, #177:
URL: https://github.com/apache/openjpa/pull/177
The four schema management methods each built a `Broker` through
`newBrokerImpl()` only to call `getClassLoader()` on it. That loader was always
`null`: `BrokerImpl` assigns it in `initialize()`, which `newBrokerImpl()`
never reaches, so the broker was asked a question it structurally could not
answer and then dropped.
They now pass the thread context class loader, which is the value
`initialize()` would have assigned, and which `postCreationCallback()` already
passes for the same `synchronizeMappings()` calls.
Closing the broker instead was not available: `close()` runs `free()`, which
dereferences a cache an uninitialized broker has not got, so a `finally {
broker.close(); }` would have turned four working methods into four that throw.
Nothing heavyweight leaked either — without `initialize()` there is no store
manager, no connection and no registration with the factory; the cost was a
finalizable object per call whose finalizer threw and was discarded.
The only behaviour that changes is that a class loader now reaches
`MappingTool`, so a custom `openjpa.Sequence` class resolves where it
previously fell back to the bootstrap loader.
Routing through `getClassResolverInstance()` was considered and rejected:
where OpenJPA's own loader differs from the context loader it returns a
`MultiClassLoader` that is then re-resolved downstream against a different
context class, producing a nesting an initialized broker would never produce.
The ticket also names `dropPersistenceStrucuture` and
`validatePersistenceStruture`; cbb19f777 has since corrected both spellings.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
