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 Sun, 24 Jan 2010 21:53:58 GMT
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
View raw message