might be a lift-specific problem with those browsers. On Sun, Jan 24, 2010 at 10:53 PM, Sig Rinde <[email protected]> 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 <[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 > >>>>> >> > >>>>> > > >>>>> > >>>> > >>> > >> > > >
