esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: Wee error
Date Mon, 25 Jan 2010 07:00:09 GMT
might be a lift-specific problem with those browsers.

On Sun, Jan 24, 2010 at 10:53 PM, Sig Rinde <sig@rinde.com> wrote:

> Now this is interesting:
>
> Cleaned out cookies so I could log on again.
> Created a new user logged on without any glitch in Chrome, Safari and
> Firefox.
> Logged out.
> Signed on as api_test: Same problem in Chrome (dev version) and Safari
> (latest), but all was OK in Firefox 3.5.5
>
> Repeat and rinse, same each time.
>
> Hmmm...
>
>
>
>
>
> 2010/1/24 Ethan Jewett <esjewett@gmail.com>:
> > Hi Sig,
> >
> > In the svn repo that user is only set up in test.default.props, which
> > I'm pretty sure is only loaded when run in test mode. You might have
> > added the line in default.props. The idea was for people to take
> > responsibility for creating and setting their own admin users if they
> > are deploying in an integration setting, which it seems is exactly
> > what you've done. No problem there.
> >
> > Ok, so what is causing the problem? The copy of the webapp folder is
> > definitely a possibility. What I'd do if I were you is get everything
> > possible in sync with the trunk svn repo, including deleting the
> > duplicate webapp folder, when doing an "svn status" and reverting
> > ("svn revert path/filename") all changes that are not necessary for
> > your deployment to function. If you see a file listed in "svn status"
> > and you're not sure why it's there, you can do an "svn diff
> > path/filename" and see exactly what differences there are from trunk.
> >
> > Once you're as synced up as you can get, if you are still having
> > issues, can you outline all the differences between your deployment
> > and our trunk so that we can try to recreate your issue?
> >
> > Thanks,
> > Ethan
> >
> > On Sun, Jan 24, 2010 at 2:31 PM, Sig Rinde <sig@rinde.com> wrote:
> >> Only user api_test. All other users are added via api getting tokens
> >> directly (i.e. I do not have a password for those).
> >>
> >> First thing first time the ESME server was started I signed up
> >> api_test in order to create the api_test token that allows the rest to
> >> happen from our side.
> >>
> >> Not entirely sure why 'api_test' was chosen, I assume any user could
> >> be used as long as the default.props file has the user name. Locally
> >> we have no problems using exact same setup with 'api_test' as admin
> >> user.
> >>
> >> Installation is on an Amazon instance, same as where the Thingamy
> >> instances are running.
> >>
> >> Tried server restart, svn anew, the usual, no change.
> >>
> >> OK, have to admit to one (amateur) stunt as follows:
> >>
> >> 1. After having signed up as api_test and produced the token I renamed
> >> webapp folder to disallow any access to admin interface.
> >> 2. Forgot about that when we did an svn up later, which of course
> >> produced a new webapp.
> >>
> >> Could that have messed up?
> >>
> >>
> >> 2010/1/24 Ethan Jewett <esjewett@gmail.com>:
> >>> Hi Sig,
> >>>
> >>> I am surprised that you are getting this error. When I try to log in
> >>> as api_test, I just get a message that says "Unknown credentials". In
> >>> other words, I can't recreate your error, so we need some more
> >>> information, I think.
> >>>
> >>> A bit of further information: "api_test" is the test user that is
> >>> created for use in the api unit tests. It is created by those tests,
> >>> so if you are running a "mvn jetty:run" that user will not exist.
> >>> Still should not result in that error, but just wanted to be clear
> >>> that this user probably won't help you much.
> >>>
> >>> Ethan
> >>>
> >>> On Sun, Jan 24, 2010 at 2:03 PM, Richard Hirsch <hirsch.dick@gmail.com>
> wrote:
> >>>> Is the login problem just api_test or all users?
> >>>>
> >>>> Is the installation local or in the cloud?
> >>>>
> >>>> Tried a server restart to see if problem disappears?
> >>>>
> >>>> D.
> >>>>
> >>>> On Sun, Jan 24, 2010 at 8:15 PM, Sig Rinde <sig@rinde.com> wrote:
> >>>>
> >>>>> (Sorry for not doing all in one :)
> >>>>>
> >>>>> Server works, pools behaving as they should. Only the login messed
> up...
> >>>>>
> >>>>>
> >>>>> 2010/1/24 Sig Rinde <sig@rinde.com>:
> >>>>> > Actually this happened when logging in as 'api_test'
> >>>>> >
> >>>>> > [default.props has this extra line:
> role.api_test=integration-admin]
> >>>>> >
> >>>>> >
> >>>>> > 2010/1/24 Sig Rinde <sig@rinde.com>:
> >>>>> >> When trying to get into urltohost:8080 I get this (just
the upper
> part
> >>>>> >> of a ton):
> >>>>> >>
> >>>>> >> Exception occured while processing/
> >>>>> >> Message: java.lang.UnsupportedOperationException: unsuitable
as
> hash key
> >>>>> >>
>  scala.collection.mutable.Buffer$class.hashCode(Buffer.scala:280)
> >>>>> >>
> >>>>>  scala.collection.mutable.ArrayBuffer.hashCode(ArrayBuffer.scala:26)
> >>>>> >>        scala.xml.Utility$.hashCode(Utility.scala:263)
> >>>>> >>        scala.xml.Elem.hashCode(Elem.scala:64)
> >>>>> >>
> >>>>>
>  scala.collection.mutable.FlatHashTable$class.elemHashCode(FlatHashTable.scala:144)
> >>>>> >>
>  scala.collection.immutable.HashSet.elemHashCode(HashSet.scala:39)
> >>>>> >>
> >>>>>
>  scala.collection.mutable.FlatHashTable$class.containsEntry(FlatHashTable.scala:56)
> >>>>> >>
> >>>>>  scala.collection.immutable.HashSet.containsEntry(HashSet.scala:39)
> >>>>> >>        scala.collection.immutable.HashSet.$plus(HashSet.scala:60)
> >>>>> >>
> >>>>>
>  scala.collection.immutable.Set$$anonfun$$plus$plus$1.apply(Set.scala:73)
> >>>>> >>
> >>>>>
>  scala.collection.immutable.Set$$anonfun$$plus$plus$1.apply(Set.scala:73)
> >>>>> >>        scala.Iterator$class.foldLeft(Iterator.scala:520)
> >>>>> >>
> >>>>> >> Latest per svn, jetty:run behaved... server seems to be
running,
> >>>>> >> although I'm suspecting some pool issues... that's what
I wanted
> to
> >>>>> >> check.
> >>>>> >>
> >>>>> >> Sig
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message