Just fixed that by adding a new single class Maven module for the
agent that has no dependencies on anything, and thus can be
bootstrapped without much trouble (rather cayenne-jpa module depends
on cayenne-jpa-agent).
Will be moving integration tests to the main Maven tree shortly.
Andrus
On Aug 10, 2006, at 4: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"). 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...
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.
Andrus
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!
