I don't want to change Listing to be non-abstract, but I did try querying a concrete subclass and that doesn't suffer from the same defect. So that raises/reiterates a few questions
1) Can't you, via HQL, query an interface or abstract class entity with the goal of getting a collection of all objects in a class hierarchy, where the actual instantiated types are correctly resolved by hibernate? 2) Why in the world does this work if I query one specific entity - even subsequent requests for the same one - until I query a different one at which point it is permanently broken? 3) Even though I'm not having this in my page class where I need all of the varying subclass entity instances in a single collection, should I be worried? I imagine the answer to #1 will answer this. I haven't verified that this happens in a non-T5 context, but I'll test that later and share my findings. chris 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
