incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sig Rinde <...@rinde.com>
Subject Re: Wee error
Date Tue, 26 Jan 2010 14:33:46 GMT
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/trunk esme

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 <hirsch.dick@gmail.com>:
> 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 <sig@rinde.com> 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 <hirsch.dick@gmail.com>:
>> > what happens if you don't comment out the plug-in
>> >
>> > On Tue, Jan 26, 2010 at 2:25 PM, Sig Rinde <sig@rinde.com> 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 <esjewett@gmail.com>:
>> >> > 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 <sig@rinde.com> 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 <esjewett@gmail.com>:
>> >> >>> 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 <sig@rinde.com>
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 <hirsch.dick@gmail.com>:
>> >> >>>>> might be a lift-specific problem with those browsers.
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>>
>

Mime
View raw message