Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] minor changes to PersistenceProvider to support custom PersistenceInitializationHelper

A lot of questions ... I'll try to summarize things:

- yes, this is primarily focused on testing, so I don't think users will be installing their own custom PersistenceInitializationHelper's
  (but who knows, it might be useful for them as well)
- no internal API's required, everything is public:
    PersistenceProvider provider = new org.eclipse.persistence.jpa.PersistenceProvider();
    ((org.eclipse.persistence.jpa.PersistenceProvider)provider).setInitializationHelper(
        new DynamicPersistenceInitializationHelper());
    EntityManagerFactory emf = provider.createEntityManagerFactory(
        "someName", getDatabaseProperties());

- there are many examples throughout EclipseLink where - because of the nature of test environments, DB setup, etc - tests are not 'real world'
  It is not always required - or possible - to exactly reproduce 'end user usage'
- I'll leave the issue of "alternate persistence.xml location for all of JPA" for others to answer - I don't know what is/is not allowed by spec or convention

Would a code review be helpful?
---
Mike Norman

Gordon Yorke wrote:
Is this change just for testing?  If it is why are the tests not written as the user would use the functionality?  Seems we would not be testing the end user usage which questions why we are testing at all?

If it is not just for testing what user is going to feel comfortable creating an instance of our PersistenceProvider, setting a special initializer and then calling internal SPI to get a EntityManagerFactory.  Why is the current code not being updated to handle the specific requirements of dynamic persistence?  How would this mechanism work concurrently with non Dynamic Persistence Deployments?  All of the issues mentioned in your email are easily resolved currently or will not be resolved by this change. ( weaving : eclipselink.weaving property, orm.xml : not required by JPA impl, temp classloader: this change will not alter classloader usage) What requirements will be resolved by this functionality that can not be resolved by existing means?

Support for alternate persistence.xml locations should be for all of JPA not just dynamic persistence.

The PersistenceInitializationHelper was designed to encapsulate running in different environments that would be consistent across all PersistenceUnits and API invocations not to support alternate configurations for a few specific Persistence Units.

--Gordon

Mike Norman wrote:
As part of the work for 200045, I have been working to get some JPA-style Dynamic Persistence tests added to
eclipselink.jpa.test. However, Dynamic Persistence doesn't support weaving, orm.xml files, temp classloaders and
a bunch of other JPA-specific details. I have opened a bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=292152
to track some changes so that a custom PersistenceInitializationHelper can be installed on a PersistenceProvider
(this will also allow resources to be loaded from locations other than META-INF/persistence.xml - rather useful for testing).

I went over the changes with Tom Ware and am now sending this out to the dev community for comments - the patch
is attach'd to the above bug.

Thanks in advance,
--
Mike Norman

Back to the top