Copying $JROCKIT_HOME/lib/tools.jar to
$JROCKIT_HOME/jre/lib/ext/tools.jar fixed this problem. The reason
this happened is probably because I chose *not* to use JRockit as my
default JRE.
Matt
On 3/8/07, Matt Raible <[EMAIL PROTECTED]> wrote:
Maybe I spoke too soon, it looks like there's issues using JRockit
with the native2ascii plugin:
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error starting Sun's native2ascii:
sun.tools.native2ascii.Main
[INFO] ------------------------------------------------------------------------
[INFO] Trace
Error starting Sun's native2ascii:
at
org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:67)
at
org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
tive2Ascii.java:54)
at
org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
at
org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
at
org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
at
org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
ycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at
org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:51)
... 23 more
--- Nested Exception ---
java.lang.ClassNotFoundException: sun.tools.native2ascii.Main
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:164)
at
org.apache.tools.ant.taskdefs.optional.native2ascii.SunNative2Ascii.run(SunNative2Ascii.j
ava:51)
at
org.apache.tools.ant.taskdefs.optional.native2ascii.DefaultNative2Ascii.convert(DefaultNa
tive2Ascii.java:54)
at
org.apache.tools.ant.taskdefs.optional.Native2Ascii.convert(Native2Ascii.java:268)
at
org.apache.tools.ant.taskdefs.optional.Native2Ascii.execute(Native2Ascii.java:227)
at
org.codehaus.mojo.native2ascii.Native2AsciiMojo.executeAnt(Native2AsciiMojo.java:115)
at
org.codehaus.mojo.native2ascii.Native2AsciiMojo.execute(Native2AsciiMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor
.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifec
ycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.
java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultL
ifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleE
xecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 minutes 2 seconds
[INFO] Finished at: Thu Mar 08 11:34:49 MST 2007
[INFO] Final Memory: 226M/512M
[INFO] ------------------------------------------------------------------------
$
On 3/8/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> JRockit in general seems to work great. I installed it about an hour
> ago and did some testing. I was able to run "mvn jetty:run" and
> compile classes (to invoke a restart) about 15 times. I gave up after
> that. With Sun's JDK 6, I get a PermGen error after reload #4.
>
> Summary: Use JRockit for developing AppFuse!
>
> http://commerce.bea.com/products/weblogicjrockit/jrockit_prod_fam.jsp
>
> If you're developing an AppFuse 2.x-based application, please download
> JRockit and try it out. I'll check back next week and see how it's
> going for everyone. If good, we'll change the download link to
> JRockit on the QuickStart Guide.
>
> Matt
>
> P.S. I don't think this means you have to use JRockit for production,
> just when you're reloading a lot during development.
>
> On 3/8/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> > An XML snippet would be great. Do you think it's possible to delegate
> > to one Sun JVM for testing and another for running? For example, test
> > under JDK 5, run under JDK 6.
> >
> > Matt
> >
> > On 3/8/07, Philip Barlow <[EMAIL PROTECTED]> wrote:
> > > Yes, exactly, surefire allows you to specify an independent JVM for
> > > tests, separate to your deployment JVM. We use Suns JVM for deployment
> > > and JRockit for tests now. the JVM can be declared in your POM under the
> > > configuration for the surefire-plugin. If you need any more info on this
> > > let me know.
> > >
> > > Matt Raible wrote:
> > > > Philip,
> > > >
> > > > What's your configuration for this look like? I'm assuming you just
> > > > use JRockit for your tests, but you still use Sun's JVM for "mvn
> > > > jetty:run"?
> > > >
> > > > Matt
> > > >
> > > > On 3/8/07, Philip Barlow <[EMAIL PROTECTED]> wrote:
> > > >> I had this problem in work recently, i set surefire to use JRockit as
> > > >> the JVM for tests and it worked every time. I realise this is not a fix
> > > >> but i have read alot about this subject and there a very differing
> > > >> opinions on it. Matt is correct in stating that resources are not being
> > > >> released but JRockit seems to do ok in this respect.
> > > >>
> > > >> This would be helpfull if you decide to take this course of action.
> > > >>
> > > >> http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html
> > > >>
> > > >>
> > > >>
> > > >> Matt Raible wrote:
> > > >> > I have MaxPermSize set to 256M on my system and I still get this
issue
> > > >> > every 5-10 minutes. My guess is resources aren't being let go. I've
> > > >> > heard bad things about Spring and Hibernate in the past, so I don't
> > > >> > know if they're causing this or what. The best thing is probably to
> > > >> > slap a profiler on it and see where the hotspots and memory leaks
are.
> > > >> >
> > > >> > Matt
> > > >> >
> > > >> > On 3/7/07, wnqq <[EMAIL PROTECTED]> wrote:
> > > >> >>
> > > >> >> Environment: v2.0-m4-SNAPSHOT
> > > >> >>
> > > >> >> It is too often to get "java.lang.OutOfMemoryError: PermGen space"
> > > >> while
> > > >> >> executing "mvn jetty:run".
> > > >> >>
> > > >> >> How to resolve it?
> > > >> >>
> > > >> >> I know that traditionally we could specify the JVM parameters like
> > > >> >> "-Xmx512M
> > > >> >> -XX:PermSize=64M -XX:MaxPermSize=128M" to increase the memory size.
> > > >> >> How does
> > > >> >> this apply to appfuse/mvn?
> > > >> >> --
> > > >> >> View this message in context:
> > > >> >>
> > > >>
http://www.nabble.com/mvn-jetty%3Arun-%3D%3E-OutOfMemoryError%3A-PermGen-space-tf3367253s2369.html#a9368515
> > > >>
> > > >> >>
> > > >> >> Sent from the AppFuse - User mailing list archive at Nabble.com.
> > > >> >>
> > > >> >>
---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > >> For additional commands, e-mail: [EMAIL PROTECTED]
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > http://raibledesigns.com
> >
>
>
> --
> http://raibledesigns.com
>
--
http://raibledesigns.com
--
http://raibledesigns.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
