What are the other differences on the two servers Sig?
/Anne Kathrine
Sent from my iPhone
On 26. jan. 2010, at 16.09, Sig Rinde <[email protected]> wrote:
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.
