I have, on the other server that runs ok (except that original api_test login issue) it's same OpenJDK, basically everything is same... (I'm sure that did not help much LOL)
2010/1/26 Anne Kathrine Petterøe <[email protected]>: > I don't think anything has changed. Just that no one has used openJDK since > then. > > /Anne Kathrine > Sent from my iPhone > > On 26. jan. 2010, at 16.01, Richard Hirsch <[email protected]> wrote: > >> But what has changed so that the problem now occurs? >> >> On Tue, Jan 26, 2010 at 3:52 PM, Anne Kathrine Petterøe >> <[email protected]>wrote: >> >>> Yay! :-) >>> >>> On 26. jan. 2010, at 15.50, Sig Rinde wrote: >>> >>>> Aha :) >>>> >>>> java version "1.6.0_0" >>>> OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu12) >>>> OpenJDK Client VM (build 14.0-b08, mixed mode, sharing) >>>> >>>> Sig >>>> >>>> 2010/1/26 Vassil Dichev <[email protected]>: >>>>> >>>>> We've had this before: >>>>> >>>>> >>> >>> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/200910.mbox/%[email protected]%3e >>>>> >>>>> The interesting part is that noone has implemented David's suggestion >>>>> to date, and still the problem seems to have been resolved (or was >>>>> it?) >>>>> >>>>> BTW what JDK are you using? I've had my share of problems on >>>>> Debian/Ubuntu because package management decided to pull openjdk-6, >>>>> which was not mature enough to run bug-free. >>>>> >>>>> Vassil >>>>> >>>>> >>>>> On Tue, Jan 26, 2010 at 4:37 PM, Richard Hirsch <[email protected]> >>> >>> wrote: >>>>>> >>>>>> I'm going to try it locally to see if it works on my laptop >>>>>> >>>>>> On Tue, Jan 26, 2010 at 3:33 PM, Sig Rinde <[email protected]> wrote: >>>>>> >>>>>>> Nothing I can see has changed, this one is absolutely up-to-date >>>>>>> Ubuntu 9.04 following apt-get update and upgrade after starting up a >>>>>>> fresh image. >>>>>>> >>>>>>> Then: >>>>>>> apt-get install subversion >>>>>>> apt-get install maven2 >>>>>>> apt-get install jetty >>>>>>> >>>>>>> Then: >>>>>>> svn checkout http://svn.apache.org/repos/asf/incubator/esme/trunkesme >>>>>>> >>>>>>> Then fixing the two files. >>>>>>> >>>>>>> Then problem :) >>>>>>> >>>>>>> Now: rm -rf esme and started over >>>>>>> >>>>>>> One never knows where I could have messed up, only mishap was that I >>>>>>> lost contact with the server at some point during first mvn... so now >>>>>>> I did & and logged out leaving it alone... lets see now: >>>>>>> >>>>>>> Nope, exact same error. >>>>>>> >>>>>>> Noticed that it starts saying compiling 49 packages, then dies after >>>>>>> a >>>>>>> bit, and when trying again it says compiling 8 packages. No other >>>>>>> clues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2010/1/26 Richard Hirsch <[email protected]>: >>>>>>>> >>>>>>>> RE plug-in: I remember. >>>>>>>> >>>>>>>> I think something else (Scala, lift, etc.) might have changed. Has >>>>>>> >>>>>>> anything >>>>>>>> >>>>>>>> else changed in the environment? >>>>>>>> >>>>>>>> It is all very strange. It is obviously a maven-related problem, >>> >>> because >>>>>>>> >>>>>>>> ESME's code hasn't really changed at all in the last few weeks. >>>>>>>> >>>>>>>> On Tue, Jan 26, 2010 at 2:51 PM, Sig Rinde <[email protected]> wrote: >>>>>>>> >>>>>>>>> Then I get this: >>>>>>>>> >>>>>>>>> [ERROR] FATAL ERROR >>>>>>>>> [INFO] >>>>>>>>> >>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> [INFO] null >>>>>>>>> [INFO] >>>>>>>>> >>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> [INFO] Trace >>>>>>>>> java.lang.RuntimeException >>>>>>>>> at >>>>>>>>> >>>>>>> >>> >>> com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299) >>>>>>>>> >>>>>>>>> at >>>>>>>>> >>>>>>> >>> >>> com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335) >>>>>>>>> >>>>>>>>> at >>>>>>>>> >>>>>>> >>> >>> com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:532) >>>>>>>>> >>>>>>>>> at >>>>>>>>> >>>>>>> >>> >>> net.sf.alchim.mojo.yuicompressor.YuiCompressorMojo.processFile(YuiCompressorMojo.java:178) >>>>>>>>> >>>>>>>>> at >>>>>>>>> >>>>>>> >>> >>> net.sf.alchim.mojo.yuicompressor.MojoSupport.processDir(MojoSupport.java:151) >>>>>>>>> >>>>>>>>> BTW, it was you who suggested doing this last time, and then all >>>>>>>>> was >>>>>>>>> ok for basically same setup (that was Jan 5th) :) >>>>>>>>> >>>>>>>>> >>>>>>>>> 2010/1/26 Richard Hirsch <[email protected]>: >>>>>>>>>> >>>>>>>>>> what happens if you don't comment out the plug-in >>>>>>>>>> >>>>>>>>>> On Tue, Jan 26, 2010 at 2:25 PM, Sig Rinde <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Ethan, >>>>>>>>>>> >>>>>>>>>>> this is a completely new install so I'm using "mvn jetty:run" >>>>>>>>>>> >>>>>>>>>>> Prior to that: >>>>>>>>>>> 1. svn the full esme >>>>>>>>>>> 2. add line to default.props >>>>>>>>>>> 3. comment out plugin in pom.xml >>>>>>>>>>> >>>>>>>>>>> using -e gave this at the end: >>>>>>>>>>> >>>>>>>>>>> [INFO] Trace >>>>>>>>>>> org.apache.maven.BuildFailureException: command line returned >>>>>>> >>>>>>> non-zero >>>>>>>>>>> >>>>>>>>>>> value:1 >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:924) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:767) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:529) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>> >>>>>>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>> >>>>>>> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) >>>>>>>>>>> >>>>>>>>>>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) >>>>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> >>> Method) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>>>> >>>>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:616) >>>>>>>>>>> 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: org.apache.maven.plugin.MojoFailureException: command >>> >>> line >>>>>>>>>>> >>>>>>>>>>> returned non-zero value:1 >>>>>>>>>>> at >>> >>> org.scala_tools.maven.JavaCommand.run(JavaCommand.java:196) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.scala_tools.maven.ScalaCompilerSupport.compile(ScalaCompilerSupport.java:124) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.scala_tools.maven.ScalaCompilerSupport.doExecute(ScalaCompilerSupport.java:54) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> org.scala_tools.maven.ScalaMojoSupport.execute(ScalaMojoSupport.java:208) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.scala_tools.maven.ScalaCompilerSupport.execute(ScalaCompilerSupport.java:29) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.scala_tools.maven.ScalaTestCompileMojo.execute(ScalaTestCompileMojo.java:58) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) >>>>>>>>>>> >>>>>>>>>>> at >>>>>>>>>>> >>>>>>>>> >>>>>>> >>> >>> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) >>>>>>>>>>> >>>>>>>>>>> ... 20 more >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2010/1/26 Ethan Jewett <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> Hi Sig, >>>>>>>>>>>> >>>>>>>>>>>> Can you give the full stack trace - I don't think this once goes >>>>>>> >>>>>>> deep >>>>>>>>>>>> >>>>>>>>>>>> enough for us to see if the error is in ESME or somewhere else? >>> >>> And >>>>>>>>>>>> >>>>>>>>>>>> exactly what command are you running that results in this error? >>>>>>> >>>>>>> mvn >>>>>>>>>>>> >>>>>>>>>>>> clean install? >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Ethan >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jan 26, 2010 at 4:55 AM, Sig Rinde <[email protected]> >>> >>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks Ethan, >>>>>>>>>>>>> >>>>>>>>>>>>> planned to start over to test all fresh, so I created a new and >>>>>>> >>>>>>> fresh >>>>>>>>>>>>> >>>>>>>>>>>>> Amazon instance (same base image as the other live one), >>>>>>>>>>>>> apt-get >>>>>>>>>>>>> upgrade etc, now running 9.04 all latest. >>>>>>>>>>>>> >>>>>>>>>>>>> New svn from esme. >>>>>>>>>>>>> >>>>>>>>>>>>> Added new api_test user in default.props and commented out the >>>>>>>>>>>>> compression plug-in in pom.xml. >>>>>>>>>>>>> >>>>>>>>>>>>> Then fired it up and got this error: >>>>>>>>>>>>> >>>>>>>>>>>>> [INFO] suggestion: remove the scalaVersion from pom.xml >>>>>>>>>>>>> [ERROR] /home/files/esme/server/src/test/scala >>>>>>>>>>>>> [ERROR] /home/files/esme/server/src/test/scala/../scala >>>>>>>>>>>>> [INFO] Compiling 8 source files to >>>>>>>>>>> >>>>>>>>>>> /home/files/esme/server/target/test-classes >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] Exception in thread "main" >>> >>> java.lang.StackOverflowError >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>> scala.tools.nsc.symtab.Symbols$ClassSymbol.owner(Symbols.scala:1563) >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>>>>>> >>>>>>> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:940) >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>>>>>> >>>>>>> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>>>>>> >>>>>>> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>>>>>> >>>>>>> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >>>>>>>>>>>>> >>>>>>>>>>>>> [WARNING] at >>>>>>>>>>> >>>>>>> >>>>>>> scala.tools.nsc.symtab.Symbols$Symbol.toplevelClass(Symbols.scala:942) >>>>>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> So what did I forget this time :) >>>>>>>>>>>>> >>>>>>>>>>>>> S >>>>>>>>>>>>> >>>>>>>>>>>>> 2010/1/25 Ethan Jewett <[email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Sig, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for doing all that detective work. Unfortunately I >>>>>>>>>>>>>> don't >>>>>>> >>>>>>> have >>>>>>>>>>>>>> >>>>>>>>>>>>>> an Ubuntu box to test on. :-( >>>>>>>>>>>>>> >>>>>>>>>>>>>> I wonder if there is some place that I pull in the setting for >>>>>>> >>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>> integration test user other than in the API2 code. Definitely >>>>>>>>>>>>>> possible. I will try to look in to it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question if you have the time: If you add another line in the >>>>>>>>> >>>>>>>>> property >>>>>>>>>>>>>> >>>>>>>>>>>>>> file and assign a second user as integration admin, does that >>>>>>> >>>>>>> user >>>>>>>>>>>>>> >>>>>>>>>>>>>> stop working in the web interface as well? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jan 25, 2010 at 3:27 AM, Sig Rinde <[email protected]> >>>>>>> >>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Morning creative sleuth work: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1. Sorry, no difference between browsers: >>>>>>>>>>>>>>> 2. If I log on as another user, then log out in anything but >>>>>>> >>>>>>> root, >>>>>>>>> >>>>>>>>> say >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "hosturl:8080/auth_view/" then no problem. >>>>>>>>>>>>>>> 3. If I log out and log on as api_test in root same problem >>>>>>>>>>>>>>> on >>>>>>> >>>>>>> all >>>>>>>>>>> >>>>>>>>>>> browsers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 4. This only for the aws instance, not for my local instance. >>>>>>> >>>>>>> (aws >>>>>>>>> >>>>>>>>> is >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ubuntu, local is OS X) >>>>>>>>>>>>>>> 5. Did a diff between the two (local and aws) webapp folders >>> >>> and >>>>>>>>> >>>>>>>>> found >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> nothing different (except the .svn stuff which I removed >>>>>>>>>>>>>>> after >>>>>>>>> >>>>>>>>> first >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> try). >>>>>>>>>>>>>>> 6. Did a diff between full esme directories and found no diff >>>>>>>>> >>>>>>>>> except >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> .svn folders and that esme on aws held a file named >>> >>> .gitignore. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The server works though, and now I know how to get in there >>>>>>>>>>>>>>> so >>> >>> I >>>>>>>>> >>>>>>>>> can >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> live with problem and assume it'll go away with a later new >>> >>> and >>>>>>>>> >>>>>>>>> fresh >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> install... :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2010/1/25 Richard Hirsch <[email protected]>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> might be a lift-specific problem with those browsers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >
