Return-Path: Delivered-To: apmail-incubator-esme-dev-archive@minotaur.apache.org Received: (qmail 77011 invoked from network); 19 Dec 2010 15:59:07 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 19 Dec 2010 15:59:07 -0000 Received: (qmail 53645 invoked by uid 500); 19 Dec 2010 15:59:07 -0000 Delivered-To: apmail-incubator-esme-dev-archive@incubator.apache.org Received: (qmail 53587 invoked by uid 500); 19 Dec 2010 15:59:07 -0000 Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: esme-dev@incubator.apache.org Delivered-To: mailing list esme-dev@incubator.apache.org Received: (qmail 53578 invoked by uid 99); 19 Dec 2010 15:59:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Dec 2010 15:59:07 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of vdichev@gmail.com designates 209.85.214.175 as permitted sender) Received: from [209.85.214.175] (HELO mail-iw0-f175.google.com) (209.85.214.175) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Dec 2010 15:59:02 +0000 Received: by iwn8 with SMTP id 8so2556184iwn.6 for ; Sun, 19 Dec 2010 07:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=/DYaSAtHWf0VXc8Yl1gpqdSWnThKauL84bdLg2cAyvs=; b=i0bKSEl+B3/15SsiwpcLFbhiTPtqHy2re9NZjk6+B9qFp3Hjxb9wkm8bEKsKH3+BxB KKkKKvGpBYtM1Ek1rYJfSriwpAE2pHqcUWluXP1L8JNxBlPSoIXiueeXFHguIUh0oXtp wHnzOCymTNenLWOfn1e0JVB+U5hasdVW2Daw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=OH6z/LdgAU9EGG8RgyOVk54tq+2Ioi8Haw6fIrZ+wh5jsti1mYlNWFFWThnlJysUvO IWohKywbuaTsvW5xtdHeJUm3SObpHhJCJAj9IrCFLOWkko+pbiS5GgbPkKqvuZc1/yi8 pfUXV4LUnOnNFgS2LD311k27vTEkes9s99x20= MIME-Version: 1.0 Received: by 10.231.13.203 with SMTP id d11mr3019047iba.33.1292774320890; Sun, 19 Dec 2010 07:58:40 -0800 (PST) Sender: vdichev@gmail.com Received: by 10.231.36.65 with HTTP; Sun, 19 Dec 2010 07:58:40 -0800 (PST) In-Reply-To: References: Date: Sun, 19 Dec 2010 17:58:40 +0200 X-Google-Sender-Auth: ip4w1l3AFzir1wIe0GjkBxS4ftk Message-ID: Subject: Re: Actions with Lift 2.2 (was: Move to latest Lift release for 1.2) From: Vassil Dichev To: esme-dev@incubator.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Scala's Map implementation probably suppresses these warnings. On Sun, Dec 19, 2010 at 5:30 PM, Richard Hirsch wro= te: > Should we turn on warnings / deprecated code messages for the compiler > - I think both are currently suppressed. > > D > > On Sun, Dec 19, 2010 at 4:22 PM, Vassil Dichev wrote= : >> Now that you've mentioned it, I was curious why it worked. It doesn't >> have anything to do with Lift, but with Scala. Here's the reason: >> >> Let's define a simple object, which delegates equals to its member >> field (don't try this at home). >> >> ------------------------------------------------------------------------= -------- >> class Obj(i: Int) { override def equals(o: Any) =3D o =3D=3D i } >> ------------------------------------------------------------------------= -------- >> >> Now let's see what happens if you create an object and compare it with >> the same value its member field has. >> >> This is what happens in Scala 2.7.7: >> ------------------------------------------------------------------------= -------- >> 2 =3D=3D new Obj(2) >> >> warning: comparing values of types Int and Obj using `=3D=3D' will alway= s >> yield false >> =A0 =A0 =A0 2 =3D=3D new Obj(2) >> =A0 =A0 =A0 =A0 ^ >> res5: Boolean =3D true >> ------------------------------------------------------------------------= -------- >> >> Curiously, the compiler warns you that this will yield false, but >> still returns true :-) Scala 2.8 keeps its promise though, so the >> result is actually false. >> >> This would also mean that the "contains" method in a map will always >> return false now, and "get" will always return None. >> >> Vassil >> >> >> On Sun, Dec 19, 2010 at 3:55 PM, Vladimir Ivanov = wrote: >>> Ethan, Vassil >>> >>> Yes, I've got it now. Thanks for the explanation! >>> >>> 2010/12/19 Vassil Dichev >>> >>>> Yes, I'm sure that there wasn't an implicit conversion before, just as >>>> there isn't one now. Probably the definition of hashCode and/or equals >>>> has changed (let's remember that both need to work in order to get >>>> something out of a map). I don't see where exactly, but this must be >>>> it. >>>> >>>> Vassil >>>> >>>> >>>> On Sun, Dec 19, 2010 at 10:57 AM, Ethan Jewett wr= ote: >>>> > Hi Vladimir, >>>> > >>>> > You've got the first half of the problem: The MessagePullActor is se= nt >>>> > the MessagePullActor.StartPullActor(id, lastMsg, feed) message in li= ne >>>> > 214 of Action.scala. The "id" here is a MappedLongIndex. I've change= d >>>> > it to "id.is", which just returns a Long, I believe. >>>> > >>>> > The problem occurs because the MessagePullActor is sent the message >>>> > MessagePullActor.Fetch(td.performId) in line 277 of UserActor.scala. >>>> > Here the td.performId is a Long. >>>> > >>>> > Within MessagePullActor, a map is populated with "id" as the key in >>>> > the first call. In the second call the same map has get(td.performId= ) >>>> > called on it, with the intent of retrieving the map relationship >>>> > stored in the first call. But since (I guess) a Long is no longer >>>> > equal to a MappedLongIndex in Scala 2.8 (???) this doesn't work any >>>> > more. get(td.performId) just returns a None() instead of the >>>> > Some(MessagePullActor(...)) that it used to return. >>>> > >>>> > Does that seem like the right explanation to you? I'm not sure if >>>> > that's really the reason, but I assume something like that is going >>>> > on. >>>> > >>>> > Ethan >>>> > >>>> > On Sun, Dec 19, 2010 at 1:56 AM, Vladimir Ivanov >>>> wrote: >>>> >> Ethan, >>>> >> >>>> >> I have a little misunderstanding - you wrote that MappedLong had be= en >>>> used >>>> >> to search in a Map(Any, LiftActor) in MessagePullActor and Long had= been >>>> as >>>> >> a key to store value. But where had this conversion happend? I neit= her >>>> see >>>> >> it in PF below nor I can figure out what implicit conversion had be= en >>>> >> applied. It seems to me like the same obj (MappedLong) was used to = store >>>> >> value. >>>> >> >>>> >> case StartPullActor(obj, lastMessage, messageSource) =3D> >>>> >> =A0 =A0 =A0if (!messagePullActors.contains(obj)) { >>>> >> =A0 =A0 =A0 =A0val pullActor =3D new MessagePullActor(Distributor, = lastMessage, >>>> >> messageSource) >>>> >> =A0 =A0 =A0 =A0messagePullActors +=3D (obj -> pullActor) >>>> >> =A0 =A0 =A0 =A0pullActor ! StartUp >>>> >> =A0 =A0 =A0} >>>> >> >>>> >> 2010/12/19 Ethan Jewett >>>> >> >>>> >>> Ahhh, so is it accurate to say that the problem is that when the >>>> >>> parameter is Any the compiler is not doing an implicit conversion = from >>>> >>> MappedLongKey to Long, but when the parameter is Long it tips off = the >>>> >>> compiler that the implicit conversion is necessary? Of course, in = that >>>> >>> case I don't understand why this ever worked :-) >>>> >>> >>>> >>> Ethan >>>> >>> >>>> >>> On Sat, Dec 18, 2010 at 10:42 PM, Vassil Dichev >>>> >>> wrote: >>>> >>> > Thanks Ethan! I noticed now that I have tried to create a very >>>> generic >>>> >>> > Map, but now restricted the key type from Any to Long in order t= o >>>> >>> > avoid this type of error in the future. >>>> >>> > >>>> >>> > I've also just fixed a bug caused by different treatment of XML = node >>>> >>> > equality in Scala 2.7 and 2.8. If I remember correctly, many Lif= t >>>> >>> > tests failed because of this when they tried to migrate to Scala= 2.8. >>>> >>> > >>>> >>> > Vassil >>>> >>> > >>>> >>> > >>>> >>> > On Sat, Dec 18, 2010 at 10:03 PM, Ethan Jewett >>>> >>> wrote: >>>> >>> >> This is (I believe) fixed. We were using a MappedLongKey to do = a >>>> >>> >> lookup in a map but we were storing the value being looked up w= ith a >>>> >>> >> key that was just a Long. I guess this doesn't work any more? := -) >>>> >>> >> >>>> >>> >> Ethan >>>> >>> >> >>>> >>> >> On Sat, Dec 18, 2010 at 1:03 PM, Richard Hirsch < >>>> hirsch.dick@gmail.com> >>>> >>> wrote: >>>> >>> >>> Strange - There is no exception in the log file on stax. ..... >>>> >>> >>> >>>> >>> >>> D. >>>> >>> >>> >>>> >>> >>> On Sat, Dec 18, 2010 at 1:00 PM, Richard Hirsch < >>>> hirsch.dick@gmail.com> >>>> >>> wrote: >>>> >>> >>>> Let me take a look on stax to see if I see anything in the lo= g >>>> file. >>>> >>> >>>> >>>> >>> >>>> D. >>>> >>> >>>> >>>> >>> >>>> On Sat, Dec 18, 2010 at 12:38 PM, Vladimir Ivanov < >>>> >>> lester.mail@gmail.com> wrote: >>>> >>> >>>>> Hello Ethan, >>>> >>> >>>>> >>>> >>> >>>>> I just want to say that this action also works locally in tr= unk >>>> for >>>> >>> me. >>>> >>> >>>>> >>>> >>> >>>>> Thank you! >>>> >>> >>>>> >>>> >>> >>>>> 2010/12/18 Ethan Jewett >>>> >>> >>>>> >>>> >>> >>>>>> Hi Vassil, >>>> >>> >>>>>> >>>> >>> >>>>>> Cool, thanks for checking. In case it wasn't clear, Stax is >>>> >>> currently >>>> >>> >>>>>> on the Lift 2.2 build. It is where I first noticed this pro= blem. >>>> If >>>> >>> >>>>>> you build trunk locally, I think the action will work (it d= id >>>> for >>>> >>> me). >>>> >>> >>>>>> >>>> >>> >>>>>> Vladimir, no problem with the questions. Ask all you want. = We >>>> really >>>> >>> >>>>>> appreciate it :-) >>>> >>> >>>>>> >>>> >>> >>>>>> Cheers, >>>> >>> >>>>>> Ethan >>>> >>> >>>>>> >>>> >>> >>>>>> On Fri, Dec 17, 2010 at 11:19 PM, Vassil Dichev < >>>> vdichev@apache.org >>>> >>> > >>>> >>> >>>>>> wrote: >>>> >>> >>>>>> > Ethan, I tested both the test and the action, and none se= ems >>>> to >>>> >>> work >>>> >>> >>>>>> > on the stax instance. Will check locally. >>>> >>> >>>>>> > >>>> >>> >>>>>> > >>>> >>> >>>>>> > On Fri, Dec 17, 2010 at 6:53 PM, Ethan Jewett < >>>> esjewett@gmail.com >>>> >>> > >>>> >>> >>>>>> wrote: >>>> >>> >>>>>> >> I have been able to recreate this problem locally. "ever= y X >>>> min" >>>> >>> >>>>>> >> actions simply do not fire on the Lift 2.2 branch. It lo= oks >>>> like >>>> >>> the >>>> >>> >>>>>> >> scheduler never gets started but there are no error mess= ages. >>>> On >>>> >>> the >>>> >>> >>>>>> >> trunk, these types of actions still work fine. >>>> >>> >>>>>> >> >>>> >>> >>>>>> >> I am going to be pretty busy this weekend and next week,= but >>>> I'll >>>> >>> try >>>> >>> >>>>>> >> to look into it. If anyone else has any ideas or wants t= o try >>>> to >>>> >>> >>>>>> >> diagnose the problem, go for it! >>>> >>> >>>>>> >> >>>> >>> >>>>>> >> Example action that grabs my Jira items and makes them i= nto >>>> >>> messages: >>>> >>> >>>>>> >> >>>> >>> >>>>>> >> Test: every 1 mins >>>> >>> >>>>>> >> Action: rss: >>>> >>> >>>>>> >>>> >>> >>>> http://issues.apache.org/jira/sr/jira.issueviews:searchrequest-xml/tem= p/SearchRequest.xml?pid=3D12310850&reporterSelect=3Dspecificuser&reporter= =3Desjewett&sorter/field=3Dissuekey&sorter/order=3DDESC&tempMax=3D1000 >>>> >>> >>>>>> >> >>>> >>> >>>>>> >> Ethan >>>> >>> >>>>>> >> >>>> >>> >>>>>> >> On Wed, Dec 15, 2010 at 6:52 PM, Ethan Jewett < >>>> >>> esjewett@gmail.com> >>>> >>> >>>>>> wrote: >>>> >>> >>>>>> >>> There is a potential problem with actions. I created so= me >>>> new >>>> >>> Jira >>>> >>> >>>>>> >>> items that should be pulled in by my RSS pull action th= at >>>> runs >>>> >>> every 5 >>>> >>> >>>>>> >>> minutes. It's been about 10 minutes and so far I see >>>> nothing. >>>> >>> >>>>>> >>> >>>> >>> >>>>>> >>> Dick, I wonder if you have a chance, can take a look at= the >>>> Stax >>>> >>> logs >>>> >>> >>>>>> >>> and see if there is anything within the last 15 minutes= or >>>> so? >>>> >>> It is >>>> >>> >>>>>> >>> about 18:45 ECT (17:45 GMT) now, I think. I'm really ba= d at >>>> >>> timezones >>>> >>> >>>>>> >>> though, so I might be confused :-) >>>> >>> >>>>>> >>> >>>> >>> >>>>>> >>> Thanks, >>>> >>> >>>>>> >>> Ethan >>>> >>> >>>>>> >>> >>>> >>> >>>>>> >> >>>> >>> >>>>>> > >>>> >>> >>>>>> > >>>> >>> >>>>>> > >>>> >>> >>>>>> > -- >>>> >>> >>>>>> > Twitter: http://twitter.com/vdichev >>>> >>> >>>>>> > Blog: http://speaking-my-language.blogspot.com >>>> >>> >>>>>> > >>>> >>> >>>>>> >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> -- >>>> >>> >>>>> Best Regards, >>>> >>> >>>>> Vladimir Ivanov >>>> >>> >>>>> >>>> >>> >>>> >>>> >>> >>> >>>> >>> >> >>>> >>> > >>>> >>> > >>>> >>> > >>>> >>> > -- >>>> >>> > Twitter: http://twitter.com/vdichev >>>> >>> > Blog: http://speaking-my-language.blogspot.com >>>> >>> > >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Best Regards, >>>> >> Vladimir Ivanov >>>> >> >>>> > >>>> >>>> >>>> >>>> -- >>>> Twitter: http://twitter.com/vdichev >>>> Blog: http://speaking-my-language.blogspot.com >>>> >>> >>> >>> >>> -- >>> Best Regards, >>> Vladimir Ivanov >>> >> >> >> >> -- >> Twitter: http://twitter.com/vdichev >> Blog: http://speaking-my-language.blogspot.com >> > --=20 Twitter: http://twitter.com/vdichev Blog: http://speaking-my-language.blogspot.com