Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Dynamic persistence unit

Doug -

Any luck pulling something together? I'm not looking for an exhaustive example, just some code snippets would be helpful.

Thanks,
Rick

On Wed, Sep 10, 2014 at 11:29 AM, Rick Curtis <curtisr7@xxxxxxxxx> wrote:
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.

I figured this would be the case. I'm looking more at the middle of the road case. I assume a huge majority of cases can be covered with a default weaving configuration? That being said, I'm not very familiar with the EclipseLink weaving options to know how many different switches there are and how many of them are used in the wild.

there is also the fundamental case that you are now testing a configuration that is separate from the JPA specified one.

True. Testing in this manner would exclude handling / parsing of p.xml files etc, but it would make adding tests for the rest of the runtime much simpler. 

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

I'd appreciate you sharing those. I assume these examples use features that are already a part of EclipseLink?

On Wed, Sep 10, 2014 at 10:35 AM, douglas clarke <douglas.clarke@xxxxxxxxxx> wrote:
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


_______________________________________________
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



--
Rick Curtis



--
Rick Curtis

Back to the top