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 <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >>> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]>: >>>>> > 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 <[email protected]>: >>>>> >> 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 >>>>> >> >>>>> > >>>>> >>>> >>> >> >
