Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Dynamic persistence unit
Rick,

We have done a lot of work with respect to dynamic persistence units addressing both creating PUs on the fly based on concrete Java classes as well as scenarios where the domain classes themselves are created on the fly using byte-code generation.

There are two concerns I see with dynamic PUs for testing:

1. Byte-code weaving of the domain classes. In the standard class-loader configuration the domain classes will be woven once and only once. If this weaving is consistent across all persistence units and test that might share the domain class then you are fine but if the same class is used differently in different PUs then you will be challenged to have separate woven instances of the class isolated by the PU/test-case.

2. We did look at a number of ways to simplify this early on including a custom property for where the persistence.xml file is read from so that we could have a flat classpath for all test cases and supporting PUs. Besides the weaving issue in #1 there is also the fundamental case that you are now testing a configuration that is separate from the JPA specified one. This may be acceptable if managed correctly and there are adequate 'pure JPA' test cases in addition to the compliance tests.

I do have a number of dynamic PU examples I had built locally that I will review and see how best to share.

Doug


On 2014-09-09, 9:17 PM, Rick Curtis wrote:
All -

For a while now, I have wanted an easier way to test EclipseLink and tonight I finally found a few spare cycles to look at this problem. I have been looking for a way to easily create a persistence unit that only exists for the scope of an individual test. I did some poking around and found that without too many changes, I could update JPAInitializer so that a user to could create a SEPersistenceUnitInfo and pass that in as a persistence property on a .createEntityManagerFactory(....) call. This means that you could create an EMF without the requirement of having a p.xml file... the largest drawback I can see at this point is that this data structure is marked as internal, so I don't know if it is kosher to expose outside of the runtime.

Thoughts on going down this road? If I don't hear anything negative, I'll get a bug opened soon and post an initial patch.

--
Rick Curtis


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top