esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <>
Subject Re: Pool messages are displayed where they shouldn't
Date Wed, 12 May 2010 21:24:21 GMT
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(


On Thu, May 13, 2010 at 12:14 AM, Vassil Dichev <> 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 <> 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 <> 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:
>>> 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

View raw message