incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Wee error
Date Sun, 24 Jan 2010 20:54:13 GMT
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