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 15:09:40 GMT
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 <yojibee@gmail.com>:
> 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 <hirsch.dick@gmail.com> wrote:
>
>> But what has changed so that the problem now occurs?
>>
>> On Tue, Jan 26, 2010 at 3:52 PM, Anne Kathrine Petterøe
>> <yojibee@gmail.com>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 <vdichev@apache.org>:
>>>>>
>>>>> We've had this before:
>>>>>
>>>>>
>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-esme-dev/200910.mbox/%3Ccdbebedf0910282036j6cc888caw93358695c5c6c008@mail.gmail.com%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 <hirsch.dick@gmail.com>
>>>
>>> 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 <sig@rinde.com>
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 <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