Hi Andrus, On Aug 10, 2006, at 1:04 PM, Andrus Adamchik wrote:
Ok, looks like I found the problem - all Cayenne jars and all dependencies (such as jpa spec, commons-logging, etc., etc.) have to be added to the "-bootclasspath" of the forked unit test (in addition to "-javaagent").
This might be an opportunity to look at the enhancer (agent) to see why it has dependencies on Cayenne, jpa spec etc.) There should be a pretty clear separation of the enhancer contract and the Cayenne runtime behavior.
A small problem remains - Maven2 doesn't seem to have a way to expose a combined dependency classpath in the POM as a property. Sucks...I've found the Maven guys to be pretty responsive. If you describe your problem well enough, they might turn around a patch in a few days. Worst case, they will tell you how to write the fix yourself. :-)
Craig
Andrus On Aug 9, 2006, at 11:38 AM, Andrus Adamchik wrote:Hi Craig,I certainly realize the benefits of the enhancer in case of pseudo- POJO JPA-style persistence, and I agree with your design points (the same that you made during your presentation in Dublin).Unfortunately in practice it causes lots of pain, and I expect more to come. Oh well, I'll keep banging my head against this particular wall...Andrus On Aug 9, 2006, at 11:30 AM, Craig L Russell wrote:Hi Andrus,I think you will find the enhancer to be a very valuable tool to use to improve performance and the usability of Cayenne for JPA. All of the players in JPA use the enhancement concept to advantage.It's probably worthwhile working through these issues. With Java SE 5 supporting agents, it is much more portable than with previous releases.Surefire plugin will might need to be adapted to use the agent with forked jvm. I don't understand why it would be necessary if you're running in the same vm. The agent applies to all but the system class loader IIRC.By the way, you might post to open-jpa-dev alias because they use surefire for testing and they apparently have made it work ok.We can probably keep the enhancer as an optional extension for "Cayenne-like" behavior, including such "insignificant" things like lazy relationship loading.I think JPA users will expect lazy loading to work correctly. And it's not just for relationships. Any expensive field (e.g. relationship, LOB) will benefit from lazy loading semantics.Craig On Aug 9, 2006, at 6:43 AM, Andrus Adamchik wrote:Can confirm what IIRC Bill has mentioned before - using "- javaagent" option during integration testing with Maven breaks miserably. I created a separate Maven project with a piece of configuration like that:<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <forkMode>(tried all of them)</forkMode> <childDelegation>(tried true and false)</childDelegation> <argLine>-javaagent:...</argLine> </configuration> </plugin>The configuration above would load the agent, but since Maven Surefire plugin installs its own ClassLoader for the unit tests, the agent doesn't work (I saw a number of errors depending on the combination of parameters). Will probably have to do it with Ant.Also this almost make me want to rewrite the JPA context to support true POJO's without an enhancer, as I suspect we'll be plagued by enhancer related problems in various environments. We can probably keep the enhancer as an optional extension for "Cayenne-like" behavior, including such "insignificant" things like lazy relationship loading.AndrusCraig RussellArchitect, Sun Java Enterprise System http://java.sun.com/ products/jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
