I'm showing the sql and in the conditions where the query is successful it's as it should be. When it bombs it doesn't even reach the point where the query is executed. It's almost like it forgets its mappings...
Jonathan Barker wrote: > Be paranoid. Set hibernate.show_sql=true. Grab the SQL statement, and > execute it manually. > > Also, can you change Listing to be non-abstract - even if you never use it? > > > > >> -----Original Message----- >> From: Chris Lewis [mailto:[EMAIL PROTECTED] >> Sent: Thursday, July 24, 2008 15:41 >> To: Tapestry users >> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a >> Session >> >> I haven't looked at the source of hibernate (or read) to see what >> exactly goes on, but the erratic behavior of load() is precisely the >> same as this: >> >> Listing listing = (Listing)session.createQuery("from Listing >> where id=:id") >> .setLong("id", Long.parseLong(sListingId)).uniqueResult(); >> >> I just replaced the load() call with this, so now the source is: >> >> public class BinaryFileDispatcher implements Dispatcher { >> >> private Session session; >> >> public BinaryFileDispatcher(Session session) { >> this.session = session; >> } >> >> public boolean dispatch(Request request, Response response) >> throws IOException { >> >> String sListingId = request.getParameter("limg"); >> if(sListingId== null) >> return false; >> >> System.out.println("BinaryFileDispatcher.dispatch() -- " + >> sListingId); >> >> Listing listing = (Listing)session.createQuery("from Listing >> where id=:id") >> .setLong("id", Long.parseLong(sListingId)).uniqueResult(); >> >> response.setHeader("Content-Type", "text/html"); >> >> String test = "<html><body><h1>" + listing.getTitle() + >> "</h1></body></html>"; >> response.setContentLength(test.length()); >> PrintWriter writer = response.getPrintWriter("text/html"); >> writer.append(test).flush(); >> return true; >> } >> >> } >> >> >> Quick summary of the behavior with the following urls: >> >> 1) request /LStAug/?limg=1 >> works >> >> 2) request /LStAug/?limg=1 (again) >> works >> >> 3) request /LStAug/?limg=2 >> breaks >> >> 4) request /LStAug/?limg=1 >> breaks, where it worked before >> >> (restart container) >> >> 1) request /LStAug/?limg=2 >> works >> >> 2) request /LStAug/?limg=1 >> breaks >> >> 3) request /LStAug/?limg=2 >> breaks >> >> so strange. >> >> >> Jonathan Barker wrote: >> >>> I'm not sure why it WORKED. >>> >>> Session.load will try to create an instance of Listing, which it can't >>> because it is abstract. >>> >>> On the other hand, if you do a query, then even though you ask for a >>> Listing, Hibernate will look for any descendant of Listing. >>> >>> The actual object type returned will depend on the actual type for any >>> instance found. You can then cast to Listing without a problem. >>> >>> Get rid of load(). >>> >>> Jonathan >>> >>> >>> >>>> -----Original Message----- >>>> From: Chris Lewis [mailto:[EMAIL PROTECTED] >>>> Sent: Thursday, July 24, 2008 14:37 >>>> To: Tapestry users >>>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a >>>> Session >>>> >>>> Hi Jonathan, >>>> >>>> Here is my dispatcher. As you can see it's in a very early stage so >>>> >> it's >> >>>> both small and messy. The query is being done via: >>>> session.load(Listing.class, Long.parseLong(sListingId)); >>>> >>>> It was being done via createQuery and uniqueResult, with the same >>>> >> results. >> >>>> public class BinaryFileDispatcher implements Dispatcher { >>>> >>>> private Session session; >>>> >>>> public BinaryFileDispatcher(Session session) { >>>> this.session = session; >>>> } >>>> >>>> public boolean dispatch(Request request, Response response) >>>> throws IOException { >>>> >>>> String sListingId = request.getParameter("limg"); >>>> if(sListingId== null) >>>> return false; >>>> >>>> System.out.println("BinaryFileDispatcher.dispatch() -- >>>> >> " >> >>>> + sListingId); >>>> Listing listing = (Listing)session.load(Listing.class, >>>> Long.parseLong(sListingId)); >>>> >>>> response.setHeader("Content-Type", "text/html"); >>>> >>>> String test = "<html><body><h1>" + listing.getTitle() + >>>> "</h1></body></html>"; >>>> response.setContentLength(test.length()); >>>> >>>> >> response.getPrintWriter("text/html").append(test).flush(); >> >>>> return true; >>>> } >>>> >>>> } >>>> >>>> >>>> Jonathan Barker wrote: >>>> >>>> >>>>> Post your query and load code. >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Chris Lewis [mailto:[EMAIL PROTECTED] >>>>>> Sent: Thursday, July 24, 2008 13:16 >>>>>> To: Tapestry users >>>>>> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using >>>>>> >> a >> >>>>>> Session >>>>>> >>>>>> It can't be a data issue. The records are persisted via hibernate and >>>>>> work consistently as expected in pages. Like I said, I query the same >>>>>> table to which the abstract class is mapped in my index page with no >>>>>> problem at all. I also said that it works in the dispatcher for the >>>>>> first entity I query, but any subsequent query to a _different_ >>>>>> >> entity >> >>>>>> throws that exception. The query is also just a read (select). Any >>>>>> >>>>>> >>>> other >>>> >>>> >>>>>> ideas? >>>>>> >>>>>> thanks >>>>>> >>>>>> Yunhua Sang wrote: >>>>>> >>>>>> >>>>>> >>>>>>> It sounds more like a data issue, check your data in database >>>>>>> >>>>>>> >>>> carefully. >>>> >>>> >>>>>>> Yunhua >>>>>>> >>>>>>> On Wed, Jul 23, 2008 at 11:18 PM, Chris Lewis >>>>>>> >>>>>>> >>>>>>> >>>>>> <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have a dispatcher that uses a hibernate session. The dispatcher >>>>>>>> >> is >> >>>>>>>> auto bound and receives the session in the constructor. I'm using >>>>>>>> tapestry-hibernate so that session instance is a proxy that gets >>>>>>>> >> the >> >>>>>>>> real session for the current thread (right?). Now in testing my >>>>>>>> dispatcher, I give it a url like: >>>>>>>> >>>>>>>> /MyContext/?limg=2 >>>>>>>> >>>>>>>> The dispatcher looks for "limg" and if found, queries the session >>>>>>>> assuming that its value is the PK of a mapped entity. When I >>>>>>>> >> trigger >> >>>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>>> dispatcher for the first time it works fine. If I refresh the page, >>>>>>>> fine. If I change the value to something else, say 3, then it >>>>>>>> >> breaks >> >>>>>>>> with a org.hibernate.InstantiationException: >>>>>>>> >>>>>>>> Cannot instantiate abstract class or interface: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> com.mypackage.data.Listing >>>>>> >>>>>> >>>>>> >>>>>>>> If I change the value back to 2, the same thing happens! "Listing" >>>>>>>> >> is >> >>>>>>>> >>>>>> an >>>>>> >>>>>> >>>>>> >>>>>>>> abstract class mapped as a super class entity via: >>>>>>>> >>>>>>>> @Entity >>>>>>>> @Inheritance(strategy = InheritanceType.JOINED) >>>>>>>> >>>>>>>> Any clue what's going on here? Two things are perplexing me: >>>>>>>> >>>>>>>> 1) Querying mapped super classes is legal, and I in fact the same >>>>>>>> >>>>>>>> >>>> thing >>>> >>>> >>>>>>>> on my Index page with no problem. >>>>>>>> 2) The query works the first time, but as soon as the id changes it >>>>>>>> >>>>>>>> >>>> is >>>> >>>> >>>>>>>> forever broken until I restart the container. >>>>>>>> >>>>>>>> Thanks in advance! >>>>>>>> >>>>>>>> chris >>>>>>>> >>>>>>>> -- >>>>>>>> http://thegodcode.net >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------- >>>>>>>> >> -- >> >>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -------------------------------------------------------------------- >>>>>>> >> - >> >>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> http://thegodcode.net >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> http://thegodcode.net >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> -- >> http://thegodcode.net >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- http://thegodcode.net
