It doesn't sound like a blocker to me for the current release. Potentially it could be an issue if we have multiple servers using the same DB.
Marlon On 9/13/13 4:05 PM, Amila Jayasekara wrote: > Hi All, > > It seems this issue occurs due to the way we have setup encoding in mysql > database. When connecting through Linux it gets Latin* based encoding and > when going through OSX it takes UTF-8 encoding. A similar issue is > discussed in [1]. > > Further this issue occurs only in following scenario; > a. Setup database in Mac > b. Start server in Linux > c. Shut down server in Linux and start server in Mac > d. Try to login to server using XBaya > > Since above scenario is not a common deployment methodology, the issue is > not a blocker. Hence we thought of lowering the priority of the issue [2] > and planning to proceed with the release. > > If you have any different thought please let us know. > > [1] > http://stackoverflow.com/questions/730359/problems-reading-writing-utf-8-data-in-mysql-from-java-using-jdbc-connector-5-1 > [2] https://issues.apache.org/jira/browse/AIRAVATA-914 > > Thank you > Regards > Amila > > > On Wed, Sep 11, 2013 at 3:28 PM, Chathuri Wimalasena > <[email protected]>wrote: > >> Hi Amila, >> >> Error occurs from the authenticate method of the JDBCUserStore class. >> Below is the error message we get. It seems the hash generated for the >> credential does not match with the hash already saved in the database. We >> did not get this error in previous releases because we used to override >> user information at each time server is created. For this release, we >> changed it to save user information only for the initial database creation. >> >> Submitted credentials for token >> [org.apache.shiro.authc.UsernamePasswordToken - admin, rememberMe=false] >> did not match the expected credentials. >> org.apache.shiro.authc.IncorrectCredentialsException: Submitted >> credentials for token [org.apache.shiro.authc.UsernamePasswordToken - >> admin, rememberMe=false] did not match the expected credentials. >> >> Regards, >> Chathuri >> >> >> >> On Wed, Sep 11, 2013 at 12:22 PM, Chathuri Wimalasena < >> [email protected]> wrote: >> >>> Hi Amila, >>> >>> This error occurs if you are using a database which is created from an >>> airavata server which is running on a different machine. I'm debugging the >>> code. In the REST client code, the logic we have is something like this. We >>> first try to authenticate with existing cookie (without sending the >>> password in the request). If it fails and gets HTTP - 401 code, then we try >>> to authenticate using username and password with an empty cookie. In this >>> scenario, even though we provide correct username and password, request >>> does not seem to get authenticated. At this point, call is not even go for >>> the server side. Do you have any suggestions why that can be happened ? >>> >>> Regards, >>> Chathuri >>> >>> >>> On Wed, Sep 11, 2013 at 12:10 PM, Amila Jayasekara < >>> [email protected]> wrote: >>> >>>> Hi Chathuri, >>>> >>>> Any findings what causing this issue ? >>>> >>>> Thanks >>>> Amila >>>> >>>> >>>> On Wed, Sep 11, 2013 at 12:07 PM, Chathuri Wimalasena < >>>> [email protected]> wrote: >>>> >>>>> Hi All, >>>>> >>>>> I think >>>>> AIRAVATA-914<https://issues.apache.org/jira/browse/AIRAVATA-914>should be >>>>> fixed for the release. I'll update the issue as a blocker and >>>>> will work on that. >>>>> >>>>> Regards, >>>>> Chathuri >>>>> >>>>> >>>>> On Tue, Sep 10, 2013 at 7:49 AM, Amila Jayasekara < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Please note that source packs are also added to [1]. >>>>>> (both apache-airavata-0.9-SNAPSHOT-src.zip >>>>>> and apache-airavata-0.9-SNAPSHOT-src.tar.gz) >>>>>> Please verify those as well. >>>>>> >>>>>> Thanks >>>>>> Amila >>>>>> >>>>>> >>>>>> On Mon, Sep 9, 2013 at 10:12 AM, Amila Jayasekara < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Following distributions are available in [1] for testing. Due to >>>>>>> space issue we are hosting binaries in dropbox (until we resolve the >>>>>>> issue >>>>>>> with the help of apache infra). >>>>>>> >>>>>>> Server distributions *(both in zip & tar.gz formats) >>>>>>> ====================================== >>>>>>> > Standalone-Server - *apache-airavata-server-0.9- >>>>>>> SNAPSHOT-bin.zip >>>>>>> > Server-As-a-WebApp - apache-airavata-server-0.9- >>>>>>> SNAPSHOT-war.zip >>>>>>> >>>>>>> Client distributions *(both in zip & tar.gz formats) >>>>>>> ===================================== >>>>>>> > API-Client- apache-airavata-client-0.9-SNAPSHOT-bin.zip >>>>>>> > GUI-Client - apache-airavata-xbaya-gui-0.9-SNAPSHOT-bin.zip >>>>>>> >>>>>>> *Here are some pointers for testing* >>>>>>> - Verify the fixed issue for this release [2] >>>>>>> - Verify the basic workflow composition/execution/monitoring >>>>>>> scenarios from >>>>>>> Airavata 5 & 10 min tutorials [3],[4] >>>>>>> - Verify basic use-cases for Airavata API [5] are working >>>>>>> - Verify client usecases relating to Paramberoo & ODI >>>>>>> - Verify the stability with derby & mysql backend databases >>>>>>> - Verify that the XBaya JNLP distribution works (we need >>>>>>> documentation on >>>>>>> how to deploy it) >>>>>>> - Verify deploying Airavata server in a tomcat distribution >>>>>>> >>>>>>> Thank you >>>>>>> Regards >>>>>>> Amila (On behalf of Airavata PMC) >>>>>>> >>>>>>> [1] https://www.dropbox.com/sh/1boz9sap7c3w4nh/cdfA5vsLuX >>>>>>> [2] >>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20AIRAVATA%20AND%20resolution%20%3D%20Fixed%20AND%20fixVersion%20%3D%20%220.9%22%20ORDER%20BY%20priority%20DESC >>>>>>> [3] >>>>>>> >>>>>>> http://airavata.apache.org/documentation/tutorials/airavata-in-5-minutes.html >>>>>>> [4] >>>>>>> >>>>>>> http://airavata.apache.org/documentation/tutorials/airavata-in-10-minutes.html >>>>>>> [5] >>>>>>> >>>>>>> https://cwiki.apache.org/confluence/display/AIRAVATA/Gateway+Developer+Guide >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
