Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of hirsch.dick@gmail.com
 designates 209.85.161.47 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=NBi67CuDwk6CcpTDlc5gA6hFWbq0LXHg51OzLYfoAZuz+UMmLvSoKt23LfCpcXt7gk
         jVRa09ZiVqMSfzWmGQ/Jbym6mq4NaOPIFEyo7CRNzUW+o6wOUuYgEmvcoW5cp5haO8jZ
         Sl7gA3aDT/yzd4AerrJMWLmwrmXxyKPU2xoQg=
MIME-Version: 1.0
In-Reply-To: <AANLkTimP0VLc7cir3LLGx4Q7vbsbxeBk6KUhgEL9ZfY5@mail.gmail.com>
References: <AANLkTimhXA_h87o3LSw8mBBC1FZ1ykQw3uIJkmUbqJR0@mail.gmail.com>
	 <AANLkTimf94bGESEUyNk9iNGrQbZy_iTQJ1O4jwu2z6iT@mail.gmail.com>
	 <AANLkTin6zVyuJFSb2o6ey4m9UTKVBgXbA-V9CF57IIw5@mail.gmail.com>
	 <AANLkTimXsBF4NyHTY9DPcS560U9j2v3cAzziQxrF_KK8@mail.gmail.com>
	 <AANLkTikg-w76crRnge990F6B_mBVS3AnjxwZ5ETJ3Q1Q@mail.gmail.com>
	 <AANLkTimlja6UVfYBtJr7EdvXYgxlkKttEaqEuJDfpGGj@mail.gmail.com>
	 <AANLkTikEr1dQcZT4HGudUj7Fr4tdDg2g7xtxWrUBBdAv@mail.gmail.com>
	 <AANLkTikLEQzIcG_SEiQNkGg2tl4_mVICnHYLHMvQPFyt@mail.gmail.com>
	 <AANLkTikcRdB3Q9-Z3t1dYhipKBkrI_bTZwQFsswCovUt@mail.gmail.com>
	 <AANLkTimP0VLc7cir3LLGx4Q7vbsbxeBk6KUhgEL9ZfY5@mail.gmail.com>
Date: Thu, 13 May 2010 09:53:58 +0200
Message-ID: <AANLkTilOoeKEhmdGII2DGNxh9zJLU_JA7vlUqDcRI-6R@mail.gmail.com>
Subject: Re: Pool messages are displayed where they shouldn't
From: Richard Hirsch <hirsch.dick@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163642665f9e053f0486750fdf

--00163642665f9e053f0486750fdf
Content-Type: text/plain; charset=ISO-8859-1

Looks like we should add "-unchecked" to the maven plug-in in the pom.xml to
catch problems like this. There are also warnings about deprecated code as
well.


On Wed, May 12, 2010 at 11:24 PM, Vassil Dichev <vdichev@apache.org> wrote:

> Sure enough, if I enable the "-unchecked" argument to the maven-scala
> plugin, I get this warning:
>
> WARNING]
> /media/DISK_IMG/Develop/esme/src/main/scala/org/apache/esme/model/Message.scala:206:
> warning: non variable type-argument Long in type pattern is unchecked
> since it is eliminated by erasure
> [WARNING]       case Full(pools: Set[Long]) if !pools.isEmpty => List(
>
> Darn...
>
>
> On Thu, May 13, 2010 at 12:14 AM, Vassil Dichev <vdichev@apache.org>
> wrote:
> > You're certainly right, this is the one place where it expects a Set
> > of Long and the compiler doesn't catch this particular match
> > expression because of type erasure.
> >
> > Then maybe I'm seeing a different problem or it's a message from when
> > the cache is built and there are no current logged in users.
> >
> >
> > On Wed, May 12, 2010 at 11:58 PM, Ethan Jewett <esjewett@gmail.com>
> wrote:
> >> Hmmm, interesting. I was able to determine (on my machine at least) that
> >> this chunk of code wasn't executing:
> >>
> >>     case Full(pools: Set[Long]) if !pools.isEmpty => List(
> >>       BySql(" POOL in ( ?" + ( ", ?" * (pools.size - 1)) + " ) OR POOL
> IS
> >> NULL ",
> >>             IHaveValidatedThisSQL("vdichev", "22 June 2009"),
> >>             pools.toSeq:_*)
> >>
> >> Because of this, the additional Pool restriction SQL was not getting
> >> appended to the finder. The compiler wouldn't catch this because it is a
> >> matcher, so the code just runs off to the other branch of the match,
> which
> >> doesn't do anything.
> >>
> >> I changed Full(Set[Long]) to Full(List[Long]) in the matcher and it
> began
> >> appending the required SQL.
> >>
> >> I've committed the change, so you can check it out of trunk and see if
> you
> >> get the same results. Let me know how it goes, or if I'm totally off
> base.
> >>
> >> Ethan
> >>
> >>
> >> On Wed, May 12, 2010 at 4:50 PM, Vassil Dichev <vdichev@apache.org>
> wrote:
> >>
> >>> > I think I've got a fix and I'm running through the tests now. I will
> >>> check
> >>> > in shortly if all goes well. Apparently the issue is that
> viewablePools
> >>> is a
> >>> > List[Long], which no longer matches Set[Long].
> >>>
> >>> Hm, I don't think this is the case here. Nowhere is it specified that
> >>> we want a Set[Long], and even if this were a problem, the compiler
> >>> would have caught it. Check this online scala interpreter:
> >>>
> >>>
> >>>
> http://www.simplyscala.com/interp?code=val%20s%3A%20Set[Int]%20%3D%20List%281%2C%202%2C%203%29
> >>>
> >>> What happens and what Dick has also noticed is that what's inside the
> >>> yield doesn't execute. The problem here is that User.currentUser
> >>> returns Empty (this is an instance of Lift's Box, which is a container
> >>> type). This is probably related to some changes in the User's
> >>> hierarchy, but it's hard to tell why yet.
> >>>
> >>> At least the good news is that findMapDb is always called when it
> >>> should be. However, in order for it to work it must know which is the
> >>> current user- otherwise it cannot know which messages to restrict.
> >>>
> >>> Vassil
> >>>
> >>
> >
>

--00163642665f9e053f0486750fdf--