×

Discussion Board

Results 1 to 12 of 12
  1. #1
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    raccoon-0.9.2: month wrong in /logs application

    When using the /logs URL provided with raccoon-0.9.2, the date shown is off by one month.
    It shows 21/5/2007 when it should be 21/6/2007 (assumimg we do have june already ;-)

    Marv

  2. #2
    Nokia Developer Expert
    Join Date
    Mar 2003
    Posts
    457

    Re: raccoon-0.9.2: month wrong in /logs application

    Quote Originally Posted by _marv_
    When using the /logs URL provided with raccoon-0.9.2, the date shown is off by one month.
    It shows 21/5/2007 when it should be 21/6/2007 (assumimg we do have june already ;-)
    You're right.

    Hmm, interesting, that demo's been around for years now and you are the first one to point that out

    But I'll fix that.

    Johan

  3. #3
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    Re: raccoon-0.9.2: month wrong in /logs application

    Thanks Johan.

    Is the "leave a message" link on bottom of the user's "Out-Of-Site" page supposed to work?

    When using the gateway at http://www.at.openlaboratory.net:8080/<USERNAME> the link ist not there (probably it was removed), while when using a self compiled release the link is there, states "Message stored for later delivery" but the message gets never submitted.

    I assume this is because of the "newer protocol" messages in Tomcat's logfile?

    Pls. see:
    http://discussion.forum.nokia.com/fo...d.php?t=110499

    Could you put some light on these issues?

    Thanks for your support,
    Marv

  4. #4
    Nokia Developer Expert
    Join Date
    Mar 2003
    Posts
    457

    Re: raccoon-0.9.2: month wrong in /logs application

    Quote Originally Posted by _marv_
    Is the "leave a message" link on bottom of the user's "Out-Of-Site" page supposed to work?
    No. It's one internal demo we have and apparently that link was included in the distribution.

    The idea is, of course, that since mobile web servers cannot be assumed to be online all the time, the gateway can act as an intelligent intermediary. The queuing of messages for later delivery is one such activity, notifying users when a particular mobsite is online would be another.

    Could you put some light on these issues?
    I've been pushing Ferenc Dosa, who actually wrote the gateway and thus knows it the best, to respond, but he's been awfully busy lately

    Stay tuned.

    Johan

  5. #5
    Registered User
    Join Date
    Nov 2006
    Posts
    9

    Re: raccoon-0.9.2: month wrong in /logs application

    Hi,

    it has been a while since I write that demo, and lately I've been busy with something entirely different things.

    If I am not entirely mistaken, the "leave a message" should work in the OS distro.

    1) The urls like http://john.doe.at.openlaboratory.ne...essageTextHere and http://john.doe.at.openlaboratory.ne...essageTextHere work in the phone.
    2) the gw/webapps/messenger webapp is included in the gw distro - the "Leave a message" link should appear on the OutOfSight page only if the messenger webapp is deployed

    One way to check that messages are indeed accepted for delivery is that after entering the message, but before going online with the mobsite, you check the content of the MySQL db (the one configured, the table is called MUSER_PROPS, methinks) if an appropriate message property entry is added. When going online, that entry is deleted, upon (possibly unsuccessful) delivery attempt.

    The messenger webapp is one of the demos that is truly prototype in the sense that it's implementation is very insecure and has no real transaction semantics built in to the delivery. Just a demo... :-)

    The delivery itself uses HTTP. That is, the component responsible for delivering messages simply issues an HTTP request, addressing the "appropriate" mobsite links. So if you can browse to the mobsite, this should work too.

    Except, if for some reason, the URLs assumed are unavailable, like for instance when the real URLs used are not the ones assumed by the component. In your earlier post (http://discussion.forum.nokia.com/fo...d.php?t=110499) you mention that you have changed the URLs for the mobsite. The documentation for the messenger webapp also mentions similar problems.

    Incidentally, soon I hope to be able to start contributing to the gw sources, and have some time to be able to do further development and stuff. Your feedback on the thread above wrt. the "weirdo" implementation is greatly appreciated - I am sorry to say that I had no time to study the tomcat API, the gw implementation was really meant to be a prototype (in fact, I overdid my mandate, since it is more-or-less usable enough already).

  6. #6
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    Re: raccoon-0.9.2: month wrong in /logs application

    Johan and Ferenc,
    Quote Originally Posted by ferencdr
    ...
    If I am not entirely mistaken, the "leave a message" should work in the OS distro.
    Well, then is has to be a failure in my environment.

    Quote Originally Posted by ferencdr
    In fact, they do work on my side either. But of course they work only if the phone aka the user is "online". May I have a problem since I do not use the "http://<user>.at.system/" addressing scheme but "https://system/~<user>/" (or "@<user>/" in my case) scheme?

    Quote Originally Posted by ferencdr
    2) the gw/webapps/messenger webapp is included in the gw distro - the "Leave a message" link should appear on the OutOfSight page only if the messenger webapp is deployed
    Well that is the case, all webapps (beside the ones for testing) are deployed to Tomcat.

    Quote Originally Posted by ferencdr
    One way to check that messages are indeed accepted for delivery is that after entering the message, but before going online with the mobsite, you check the content of the MySQL db (the one configured, the table is called MUSER_PROPS, methinks) if an appropriate message property entry is added. When going online, that entry is deleted, upon (possibly unsuccessful) delivery attempt.
    Yes, the db entries are created as BLOB objects in the MUSERPROPS table (propname {inbox|instant}-msg, propval BLOB).
    However they never get delivered to the phone.

    Quote Originally Posted by ferencdr
    The messenger webapp is one of the demos that is truly prototype in the sense that it's implementation is very insecure and has no real transaction semantics built in to the delivery. Just a demo... :-)

    The delivery itself uses HTTP. That is, the component responsible for delivering messages simply issues an HTTP request, addressing the "appropriate" mobsite links. So if you can browse to the mobsite, this should work too.
    Could it be that only the "virtual host" addressing scheme is supported here? That would explain why sendingt he postponed messages always fails. I cannot use the virtual host addressing scheme as we're forced to use SSL (https) and there are no named based virtual hosts with https allowed (certificate name errors, an "egg vs. chicken" problem).

    Quote Originally Posted by ferencdr
    Except, if for some reason, the URLs assumed are unavailable, like for instance when the real URLs used are not the ones assumed by the component. In your earlier post (http://discussion.forum.nokia.com/fo...d.php?t=110499) you mention that you have changed the URLs for the mobsite. The documentation for the messenger webapp also mentions similar problems.
    What problems do you mention specifically? I really read all documentation reg. the webapps, may be I missed something?


    Incidentally, soon I hope to be able to start contributing to the gw sources, and have some time to be able to do further development and stuff. Your feedback on the thread above wrt. the "weirdo" implementation is greatly appreciated - I am sorry to say that I had no time to study the tomcat API, the gw implementation was really meant to be a prototype (in fact, I overdid my mandate, since it is more-or-less usable enough already).
    Well, for a proof-of-concept demo it looks rather mature and stable. I had no stability issues or hangups, it is just "it works every time or it does not work at all", which is far superior to most of the demos I've been dealing with so far.

    Thank you for your work!
    Greetings,
    Marv

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    9

    Re: raccoon-0.9.2: month wrong in /logs application

    I meant the issues listed in gw/webapps/messenger/docs/index.html.

    Since it was a while ago I have written this particular demo, it is pretty much all I can quote here. The similarity of your problem to those isssues arise from the fact that a) simple HTTP is used for delivering message to an address that may or may not be correct b) no transactional semantics provided.

    There are two issues at hand: if you have in-domain addressing even just enabled for the muser (even if it's not the one you use in your environment), then it may be picked for delivery. If you cannot access the mobsite with in-domain addressing (either because of no DNS registration of because of the url rewrite) the delivery fails. So you want to make sure that the in-path addressing is picked by the implementation (gw/gwdb/src/com/nokia/mws/gwdb/mysql/MuserNamesImpl.java:getMuserAccess). This issue is mentioned above.

    Now, in your case, even if you cleared the first obstacle, I expect to be a second snag: see gw/webapps/messenger/src/com/nokia/mws/webapps/messenger/MessageSenderUtils.java:sendMessages. This piece of code explicitly assumes the /~john.doe address valid if the access returned for the user is the name registered in "unscope", that is, the name enabled for in-path addressing. The result again is the same: the HTTP delivery will fail silently, the message is removed from the props table, and that's it.

    A proper implementation would make it configurable what the delivery address should look like at the least, and also would clear up the conceptual mess that surrounds the "default address of a muser", and would provide proper APIs for tackling it. A quick&dirty solution is to simply modify the muser URL to your liking in MessageSenderUtils.java, after making sure that the in-path address is picked for a muser.

  8. #8
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    Re: raccoon-0.9.2: month wrong in /logs application

    Ferenc,
    thank you again for your reply.

    I was reading the docs and if I understtod correctly it should work with in-path addressing (the ~ or @ scheme).

    While inspecting the tomcat's logfile I found the line
    Code:
    Jun 26, 2007 6:14:11 PM com.nokia.mws.webapps.messenger.MessageSenderUtils sendMessage
    INFO: Sending a message to 127.0.0.1:8080, /@mheerling/im
    which looks OK.

    The URL requested is thus:
    http://127.0.0.1:8080/@mheerling/im?text=MyTextHere

    But: the requested URL is password protected (by the apache on the phone side). I inserted some log4j line in MessageSenderUtils.java and tomcat logs:
    Code:
    Jun 26, 2007 6:14:12 PM com.nokia.mws.webapps.messenger.MessageSenderUtils sendMessage
    INFO: Status for message send: 401
    which is translated:
    Code:
    curl -I http://127.0.0.1:8080/@mheerling/im?text=Bla
    HTTP/1.1 401 Unauthorized
    Server: Apache-Coyote/1.1
    Connection: close
    Date: Tue, 26 Jun 2007 16:15:05 GMT
    WWW-Authenticate: Basic realm="Protected Area"
    Content-Type: text/html;charset=iso-8859-1
    Content-Length: 0
    So I try to figure out where to put the authentication info. If I'm not able to find that (I am not really a JSP expert) I would continue by disabling the authentication on phone's side.
    (Yes, I am aware of the possibly DOS risks since now anyone could trigger a huge mass of /im or /inbox requests).

    Right now, I am inspecting gw/util/src/com/nokia/mws/util/http/HttpMsg.java but do not find any references to a http-based authentication.

    I helped myself by specifying second, non-password-protected URLs as aliases for /im and /inbox in the phone's apache httpd.conf and hardwired that "suffix" in MessageSenderUtils.java.

    ant compile && ant remove && ant install

    And voila: it works!
    Thanks again!

    Marv

  9. #9
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    Re: raccoon-0.9.2: month wrong in /logs application

    After fixing the "Out-Of-Site" messaging thing, another issue i've found is the /mws-messenger part of webapps.

    Since I use only the in-path scheme (~ or @) and not the in-domain scheme, my muserid does not get displayed and so the administrator cannot send messages to me. Do you remember where I can enable the "default" addressing scheme?

    Thanks in advance,
    Marv

    P.S. If I'm asking "too much" questions or start bothering you, just drop me a PM, I know that all your support is on a voluntary base. Nevertheless I really appreciate your help ;-)

  10. #10
    Nokia Developer Expert
    Join Date
    Mar 2003
    Posts
    457

    Re: raccoon-0.9.2: month wrong in /logs application

    Quote Originally Posted by _marv_
    P.S. If I'm asking "too much" questions or start bothering you, just drop me a PM, I know that all your support is on a voluntary base. Nevertheless I really appreciate your help ;-)
    I'm sure that I speak for Ferenc as well when I say that we value your feedback and input very much.

    If there are things that would make your life easier or if you have thoughts about stuff that could and should be done, please let us know. It's impossible to say what will be implemented and in what time frame, but a pool of good ideas is always good to have.

    Johan

  11. #11
    Registered User
    Join Date
    Nov 2006
    Posts
    9

    Re: raccoon-0.9.2: month wrong in /logs application

    Hi Marv, sorry for being offline again.

    Yes, your input is not only precious, but also gives use the pleasure that someone is interested in the stuff we created. I only regret is that at the moment I cannot spend time on this.

    Anyhow: the default address: the admin webapp has this "account manager" page where you can set the default address.

  12. #12
    Registered User
    Join Date
    Jun 2007
    Posts
    13

    Re: raccoon-0.9.2: month wrong in /logs application

    Quote Originally Posted by ferencdr
    Hi Marv, sorry for being offline again.

    Yes, your input is not only precious, but also gives use the pleasure that someone is interested in the stuff we created. I only regret is that at the moment I cannot spend time on this.
    Thanks very much, I really like the idea behind MWS and Raccoon.

    Meanwhile I coded a "contacts" application for mod_python which uses the PyS60 API to access all fields of the phone's contact DB (vcard export, auto dialing clicked numbers, SMS sending, even spoken questions on the phone aka "Do you want to dial number <12345678>?" and so on). It was great fun since all worked as expected.

    Quote Originally Posted by ferencdr
    Anyhow: the default address: the admin webapp has this "account manager" page where you can set the default address.
    Yes, I was aware of that, besides it utilizes only SCOPED addresses (that is: addresses with in-domain addressing) and not in-path addressed ones. Therefore not of much use to me ;-)

    Marv

Similar Threads

  1. How can the WAP browser communicate to J2ME application?
    By hbfornies in forum Mobile Java General
    Replies: 20
    Last Post: 2007-03-02, 16:32
  2. OTA, Works in emulator not on phone, what am I doing wrong?
    By ieising in forum Mobile Java General
    Replies: 3
    Last Post: 2005-01-03, 19:48
  3. Changing the ordinal position of an exteranl application.
    By Shaikuny in forum Symbian User Interface
    Replies: 1
    Last Post: 2004-12-30, 07:32
  4. Replies: 0
    Last Post: 2004-12-13, 11:05
  5. filtering application as a recipient?
    By aidj in forum General Messaging
    Replies: 1
    Last Post: 2002-11-12, 06:26

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×