>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 7/25/06, Gary VanMatre wrote: > > > > >I was looking at adding some junit test cases for a maven build mocking > > the > > >shale mail reader JPA library in the sandbox. > > > > > >I'm using the a transaction type of "RESOURCE_LOCAL" so the test can be > > >ran under JavaSE. The problem I'm seeing is that the test needs to load > > the > > >persistence.xml from the META-INF of the target jar. It can't seem to > > find it > > >under the project's target. I'm seeing a error message that the > > "default" > > >provider can't be found. > > > > > >What am I missing here? Any ideas? > > > > It seems to work with the latest toplink archive. > > http://www.oracle.com/technology/products/ias/toplink/JPA/index.html > > > > > That's good. Just as a quick reminder, the persistence.xml file is actually > in the META-INF directory of the mailreader-jpa.jar file (i.e. the one that > contains the entity classes), not in the webapp, so be sure this JAR is on > the classpath for your tests. AFAIK that's a best practice, so you can > reuse the entity classes and persistence unit combination in multiple > environments. >
Yeap, My maven project was creating a jar artifact but the 1.0 version of top link was not finding the persistence.xml. I just installed the 2.7 version in my local maven repos and it worked like a charm. I found a glassfish unit test that I thought looked pretty interesting. https://glassfish.dev.java.net/source/browse/glassfish/entity-persistence-tests/src/java/oracle/toplink/essentials/testing/framework/junit/JUnitTestCase.java?rev=1.18&view=markup It looks like it is overriding the values in the persistence.xml with a map. I have not tried this yet but if it works, it would allow us to control the transaction type without having to swap the values in the xml file. But, I guess a better way might be just to define two persistence-unit's in the persistence.xml. One for SE and the other for EE. It looks like the use of the API regarding transactions is different depending on in container or out of container but I don't think that would stop us from creating simple junit test for the SE but deploy to an EE container. Gary > Craig
