Thanks for clarifying.
I figured out my issue with requiring the agent on Java 6, it seems to be only
an
issue on the Mac using Java 1.6.0-dp-b88-34 and unfortunately Java 6 didn't get
updated with last night's Leopard release.
It works fine with Java 5, and fine if I install the agent on Java 6 and
restart, so
it's currently not optional on the Mac + Java 6
Dario
Here's the root cause trace:
java.lang.VerifyError: (class:
org/apache/openjpa/enhance/net$nycjava$OrderItem$pcsubclass, method:
writeReplace
signature: ()Ljava/lang/Object;) Bad access to protected data
java.lang.Class.forName0(Native Method)
java.lang.Class.forName(Class.java:247)
org.apache.openjpa.util.GeneratedClasses.loadBCClass(GeneratedClasses.java:67)
org.apache.openjpa.enhance.ManagedClassSubclasser.write(ManagedClassSubclasser.java:257)
org.apache.openjpa.enhance.ManagedClassSubclasser.access$000(ManagedClassSubclasser.java:53)
org.apache.openjpa.enhance.ManagedClassSubclasser$1.write(ManagedClassSubclasser.java:123)
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:524)
org.apache.openjpa.enhance.PCEnhancer.record(PCEnhancer.java:512)
org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:144)
which causes:
Exception in thread "Attach Listener" java.lang.ClassNotFoundException:
org.apache.openjpa.enhance.InstrumentationFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:287)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:285)
Agent failed to start!
> On Oct 26, 2007, at 11:35 AM, Dario Laverde wrote:
>
>> Hi Dain,
>>
>> Just a couple of questions, how did you hookup deploying an ear
>> file into Tomcat's
>> webapps without requiring a restart or is that a false assumption)?
>
> From the restart perspective ears are much easier to deal with then
> wars, because tomcat completely ignores ear files. When we detect an
> ear file in the webapp directory, we simply kick off a normal OpenEJB
> deploy. When we get to the assembler the TomcatWebAppBuilder is
> notified of the web application and adds new contexts to Tomcat.
>
>> Are there any packaging considerations for the ear file - it still
>> has to be a collapsed correct?
>
> The feature I announced is that normal .ear files work. Collapsed
> ears have worked for a long time.
>
>> Is there a test that illustrates an example?
>
> Nope. I hacked the itests into an ear structure.
>
>> Secondly, although the installer now indicates that the openjpa
>> agent that requires
>> a restart is now optional, I still couldn't get my examples working
>> without it (even
>> on Java 6 which I assumed openjpa would make use of to avoid the
>> agent/restart).
>
> I stopped running the installer a long time ago and JPA has been
> working good for me. Can you post a the stacktrace and info about
> your application?
>
> -dain
>
