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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 > >>> > >> > > >
