You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Chris Lewis <ch...@bellsouth.net> on 2008/07/24 05:18:38 UTC
T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by Padawn <bk...@comcast.net>.
Chris Lewis-5 wrote:
>
> Do I need to do any manual hibernate cleanup? I thought this was handled
> by a background
> event but I'm at a bit of a loss...
>
Actually, Uber T5 folks, this raises a good question: when using an ORM
framework, are there specific gotcha's to be sensitive to when accessing the
ORM in a Dispatcher -vs- a Page? Tapestry does so much under the covers,
there has to be something different.
Chris, as a final volley into the clouds, I would attempt to duplicate the
error using Hibernate totally outside Tapestry first, with and without
Hibernate caching: that might clue you in.
--
View this message in context: http://www.nabble.com/T5.0.14-SNAPSHOT%3A-strange-behavior-Dispatcher-when-using-a-Session-tp18624780p18640399.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
Thiago,
You must not have read my explanation of just how erratic this is, so
here it is again:
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
The same url with a certain id breaks when you switch to another one,
after having just worked. It doesn't matter which one it is. Id one will
work until you switch. Restart container. Id 2 will work until you
switch. Restart container. My relationships are text-book cases and
completely normalized. The same query - the simplest of simple selects -
works consistently as expected in pages.
Thiago H. de Paula Figueiredo wrote:
> Em Thu, 24 Jul 2008 18:14:32 -0300, Chris Lewis
> <ch...@bellsouth.net> escreveu:
>
>> This is occurring in a development environment on a fresh and small app
>> with a schema with a total of 6 mapped entities, 7 tables, 3 records in
>> the abstract entity's table, one user (me), and all queries working
>> completely normally in the context of pages. I can't say it's impossible
>> for this to be a data issue, but the odds of that are miniscule.
>
> I don't think so. When you have an inheritence mapping, yes, you can
> have an interface or abstract class on the top. When you query for
> your Listing class, Hibernate will create a query (typically a join
> with many tables) that will load all possible Listing instances. For
> each row in the returned ResultSet, Hibernate will try to figure out
> what is its corresponding class. When it doesn't find it, it assumes
> the row is from the searched type. In this case, Listing, an abstract
> class, thus you see that error message. So it really looks to me like
> an inheritence mapping problem or some Listing table row that doesn't
> have a matching one in the subclasses tables (JOINED_TABLE inheritence
> mapping).
>
> Please post your mappings and the generated SQL query here so we can
> check them. :)
>
> Thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
http://thegodcode.net
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 24 Jul 2008 18:14:32 -0300, Chris Lewis
<ch...@bellsouth.net> escreveu:
> This is occurring in a development environment on a fresh and small app
> with a schema with a total of 6 mapped entities, 7 tables, 3 records in
> the abstract entity's table, one user (me), and all queries working
> completely normally in the context of pages. I can't say it's impossible
> for this to be a data issue, but the odds of that are miniscule.
I don't think so. When you have an inheritence mapping, yes, you can have
an interface or abstract class on the top. When you query for your Listing
class, Hibernate will create a query (typically a join with many tables)
that will load all possible Listing instances. For each row in the
returned ResultSet, Hibernate will try to figure out what is its
corresponding class. When it doesn't find it, it assumes the row is from
the searched type. In this case, Listing, an abstract class, thus you see
that error message. So it really looks to me like an inheritence mapping
problem or some Listing table row that doesn't have a matching one in the
subclasses tables (JOINED_TABLE inheritence mapping).
Please post your mappings and the generated SQL query here so we can check
them. :)
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
Brian Lough wrote:
> Right on. So imagine Snoopy's fist shake to the sky after being
> perforated by the Red Baron (Hibernate). . . ;-)
>
> You're dealing with alot of code layers, and potentially a data issue
> here (one instance you are trying to query could be represented
> in the schema just differently enough to cause this error).
This is occurring in a development environment on a fresh and small app
with a schema with a total of 6 mapped entities, 7 tables, 3 records in
the abstract entity's table, one user (me), and all queries working
completely normally in the context of pages. I can't say it's impossible
for this to be a data issue, but the odds of that are miniscule.
> Personally, I start with HibernateUtils unit tests to verify Hibernate
> and my
> low-level code first, then move to TapestryIOC outside the container
> to test the services for T5 use I've coded up, then the T5 pages: I don't
> do Hibernate in Dispatchers. Again, too many layers changing
> underneath (no offense to anyone, just the way it is): plus, I code for
> multi-frameworks.
>
> Point issue: I got nuthin', except intuition screams session cache
> hold-over (Hibernate thinks you're asking for two distinct instances
> but with the
> same persistent id). Architectural curiosity: why load in a
> dispatcher and what benefit is there?
As it turns out it doesn't make sense for what I'm writing (a binary
file dispatcher), but when I ran into this I was struck with a bolt of
"I must understand this." A realistic use however is access control, in
which you want to restrict T5-specific idioms like a "page" or "component."
>
>
> Chris Lewis wrote:
>> Padawn,
>>
>> Per your suggestion I tried the get method with the exact same results:
>>
>> Listing listing = (Listing)session.get(Listing.class,
>> Long.parseLong(sListingId));
>>
>> I also changed the dispatcher so that it uses the
>> HibernateSessionManager to get the current session explicitly on each
>> request, to no avail. I fell like something simple is evading me. My
>> dispatcher fires before the page render dispatcher, does its thing, and
>> then returns true (if handled) like any other one. Do I need to do any
>> manual hibernate cleanup? I thought this was handled by a background
>> event but I'm at a bit of a loss...
>>
>> thanks again for all the input
>>
>> snoopy dance made me laugh :-D
>>
>> Padawn wrote:
>>
>>> Since it's just my intuition speaking, I may be off-base, but...this
>>> sounds
>>> like the beloved Hibernate Proxy and/or Cache issue, both of which
>>> SnoopyDance all-over gray concurrency areas. Try substituting the
>>> query
>>> code for a, literally, straight get(persistentClass, databaseId);
>>> call and
>>> see if the issue is still there. Bit of a performance it, but
>>> better to sweat that later.
>>>
>>
>>
>
--
http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Brian Lough <bk...@comcast.net>.
Right on. So imagine Snoopy's fist shake to the sky after being
perforated by the Red Baron (Hibernate). . . ;-)
You're dealing with alot of code layers, and potentially a data issue
here (one instance you are trying to query could be represented
in the schema just differently enough to cause this error). Personally,
I start with HibernateUtils unit tests to verify Hibernate and my
low-level code first, then move to TapestryIOC outside the container to
test the services for T5 use I've coded up, then the T5 pages: I don't
do Hibernate in Dispatchers. Again, too many layers changing underneath
(no offense to anyone, just the way it is): plus, I code for
multi-frameworks.
Point issue: I got nuthin', except intuition screams session cache
hold-over (Hibernate thinks you're asking for two distinct instances but
with the
same persistent id). Architectural curiosity: why load in a dispatcher
and what benefit is there?
Chris Lewis wrote:
> Padawn,
>
> Per your suggestion I tried the get method with the exact same results:
>
> Listing listing = (Listing)session.get(Listing.class,
> Long.parseLong(sListingId));
>
> I also changed the dispatcher so that it uses the
> HibernateSessionManager to get the current session explicitly on each
> request, to no avail. I fell like something simple is evading me. My
> dispatcher fires before the page render dispatcher, does its thing, and
> then returns true (if handled) like any other one. Do I need to do any
> manual hibernate cleanup? I thought this was handled by a background
> event but I'm at a bit of a loss...
>
> thanks again for all the input
>
> snoopy dance made me laugh :-D
>
> Padawn wrote:
>
>> Since it's just my intuition speaking, I may be off-base, but...this sounds
>> like the beloved Hibernate Proxy and/or Cache issue, both of which
>> SnoopyDance all-over gray concurrency areas. Try substituting the query
>> code for a, literally, straight get(persistentClass, databaseId); call and
>> see if the issue is still there.
>> Bit of a performance it, but better to sweat that later.
>>
>>
>
>
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
Padawn,
Per your suggestion I tried the get method with the exact same results:
Listing listing = (Listing)session.get(Listing.class,
Long.parseLong(sListingId));
I also changed the dispatcher so that it uses the
HibernateSessionManager to get the current session explicitly on each
request, to no avail. I fell like something simple is evading me. My
dispatcher fires before the page render dispatcher, does its thing, and
then returns true (if handled) like any other one. Do I need to do any
manual hibernate cleanup? I thought this was handled by a background
event but I'm at a bit of a loss...
thanks again for all the input
snoopy dance made me laugh :-D
Padawn wrote:
> Since it's just my intuition speaking, I may be off-base, but...this sounds
> like the beloved Hibernate Proxy and/or Cache issue, both of which
> SnoopyDance all-over gray concurrency areas. Try substituting the query
> code for a, literally, straight get(persistentClass, databaseId); call and
> see if the issue is still there.
> Bit of a performance it, but better to sweat that later.
>
--
http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by Padawn <bk...@comcast.net>.
Since it's just my intuition speaking, I may be off-base, but...this sounds
like the beloved Hibernate Proxy and/or Cache issue, both of which
SnoopyDance all-over gray concurrency areas. Try substituting the query
code for a, literally, straight get(persistentClass, databaseId); call and
see if the issue is still there.
Bit of a performance it, but better to sweat that later.
--
View this message in context: http://www.nabble.com/T5.0.14-SNAPSHOT%3A-strange-behavior-Dispatcher-when-using-a-Session-tp18624780p18639009.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by Angelo Chen <an...@yahoo.com.hk>.
Hi,
I also use hibernate in dispatcher and some strange errors occurs, after
debugging whole day without any result, I commented out c3p0, and it works,
from there I proceeded, looks like disabling c3p0 is a good debugging method
when hibernate is giving out strange errors.
Chris Lewis-5 wrote:
>
> Yep, that solved it.
>
> <property name="hibernate.c3p0.max_statements">0</property>
>
> After that prepared statements work as normal. Doesn't the
> hibernate.c3p0.max_statements directive help improve performance though?
> I mean, wouldn't it if it didn't fall over ... ;-)
>
> Thanks Martijn, I'm glad I'm not crazy and will know to be wary of it in
> the future.
>
> chris
>
> Martijn Brinkers wrote:
>> This posting also report similar problems and it was 'solved' by
>> disabling the statement cache.
>>
>> https://jira.jboss.org/jira/browse/JBPORTAL-1287
>>
>>
>> Martijn
>>
>> On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote:
>>
>>> Sounds to me something related to the PreparedStatement cache. Do you
>>> use c3po? If so did you specify hibernate.c3p0.max_statements?
>>>
>>> Martijn
>>>
>>>
>>> On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
>>>
>>>> Ok, I've figured out what exactly is causing it and how to work around
>>>> it. I can't say why, but perhaps a resident hibernate guru will know
>>>> (it
>>>> may even be a know issue or gotcha). First off, the quick fix. This
>>>> query (and variations like load(), get(), and using the criteria api)
>>>> cause the problem:
>>>>
>>>> Listing listing = (Listing)session.createQuery("from Listing
>>>> lst
>>>> where lst.id=:id")
>>>> .setLong("id", Long.valueOf(sListingId)).uniqueResult();
>>>>
>>>> This works as expected:
>>>>
>>>> Listing listing = (Listing)session.createQuery("from Listing
>>>> lst
>>>> where lst.id=" + sListingId)
>>>> .uniqueResult();
>>>>
>>>> It seems to come down to how hibernate handles the query results when
>>>> the query is formed with a "raw" HQL string vs something like get(),
>>>> load(), the criteria api, or using query parameters as I was initially
>>>> doing. It also has something to do with the field being queried and
>>>> seems to happen only on fields that exist in each of the tables. In my
>>>> case the abstract super class Listing has the PK field "id", and the 2
>>>> subclasses also have a PK field named "id." Querying by any method
>>>> other
>>>> than "constructed strings" leads to the issue, while querying on
>>>> another
>>>> field in the super class, whose name is unique to that class, works
>>>> fine.
>>>>
>>>> So the BIG question is why in the world does it work the first time and
>>>> continue to work until the value one queries by changes?
>>>>
>>>> I'd also like to know if anyone has seen this before, and/or if it's a
>>>> known issue. I'm using a slightly outdated version of hibernate
>>>> (3.2.2.ga) and for all I know this may be fixed in more recent
>>>> versions.
>>>> My wrists are shot so I'll try tomorrow. If anyone knows of this or
>>>> gets
>>>> interested/bored enough to try it, please let me know.
>>>>
>>>> Thanks tons for all of your input.
>>>>
>>>> Sincerely,
>>>> Chris Lewis
>>>>
>>>> Chris Lewis 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
>>>>>
>>>>>
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> http://thegodcode.net
>
>
>
--
View this message in context: http://www.nabble.com/T5.0.14-SNAPSHOT%3A-strange-behavior-Dispatcher-when-using-a-Session-tp18624780p18652304.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using
a Session
Posted by "Martijn Brinkers (List)" <ma...@gmail.com>.
Could be a c3po or database driver bug. Are you using the latest
versions?
Martijn
On Fri, 2008-07-25 at 06:49 -0400, Chris Lewis wrote:
> Yep, that solved it.
>
> <property name="hibernate.c3p0.max_statements">0</property>
>
> After that prepared statements work as normal. Doesn't the
> hibernate.c3p0.max_statements directive help improve performance though?
> I mean, wouldn't it if it didn't fall over ... ;-)
>
> Thanks Martijn, I'm glad I'm not crazy and will know to be wary of it in
> the future.
>
> chris
>
> Martijn Brinkers wrote:
> > This posting also report similar problems and it was 'solved' by
> > disabling the statement cache.
> >
> > https://jira.jboss.org/jira/browse/JBPORTAL-1287
> >
> >
> > Martijn
> >
> > On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote:
> >
> >> Sounds to me something related to the PreparedStatement cache. Do you
> >> use c3po? If so did you specify hibernate.c3p0.max_statements?
> >>
> >> Martijn
> >>
> >>
> >> On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
> >>
> >>> Ok, I've figured out what exactly is causing it and how to work around
> >>> it. I can't say why, but perhaps a resident hibernate guru will know (it
> >>> may even be a know issue or gotcha). First off, the quick fix. This
> >>> query (and variations like load(), get(), and using the criteria api)
> >>> cause the problem:
> >>>
> >>> Listing listing = (Listing)session.createQuery("from Listing lst
> >>> where lst.id=:id")
> >>> .setLong("id", Long.valueOf(sListingId)).uniqueResult();
> >>>
> >>> This works as expected:
> >>>
> >>> Listing listing = (Listing)session.createQuery("from Listing lst
> >>> where lst.id=" + sListingId)
> >>> .uniqueResult();
> >>>
> >>> It seems to come down to how hibernate handles the query results when
> >>> the query is formed with a "raw" HQL string vs something like get(),
> >>> load(), the criteria api, or using query parameters as I was initially
> >>> doing. It also has something to do with the field being queried and
> >>> seems to happen only on fields that exist in each of the tables. In my
> >>> case the abstract super class Listing has the PK field "id", and the 2
> >>> subclasses also have a PK field named "id." Querying by any method other
> >>> than "constructed strings" leads to the issue, while querying on another
> >>> field in the super class, whose name is unique to that class, works fine.
> >>>
> >>> So the BIG question is why in the world does it work the first time and
> >>> continue to work until the value one queries by changes?
> >>>
> >>> I'd also like to know if anyone has seen this before, and/or if it's a
> >>> known issue. I'm using a slightly outdated version of hibernate
> >>> (3.2.2.ga) and for all I know this may be fixed in more recent versions.
> >>> My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
> >>> interested/bored enough to try it, please let me know.
> >>>
> >>> Thanks tons for all of your input.
> >>>
> >>> Sincerely,
> >>> Chris Lewis
> >>>
> >>> Chris Lewis 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
> >>>>
> >>>>
> >>>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
Yep, that solved it.
<property name="hibernate.c3p0.max_statements">0</property>
After that prepared statements work as normal. Doesn't the
hibernate.c3p0.max_statements directive help improve performance though?
I mean, wouldn't it if it didn't fall over ... ;-)
Thanks Martijn, I'm glad I'm not crazy and will know to be wary of it in
the future.
chris
Martijn Brinkers wrote:
> This posting also report similar problems and it was 'solved' by
> disabling the statement cache.
>
> https://jira.jboss.org/jira/browse/JBPORTAL-1287
>
>
> Martijn
>
> On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote:
>
>> Sounds to me something related to the PreparedStatement cache. Do you
>> use c3po? If so did you specify hibernate.c3p0.max_statements?
>>
>> Martijn
>>
>>
>> On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
>>
>>> Ok, I've figured out what exactly is causing it and how to work around
>>> it. I can't say why, but perhaps a resident hibernate guru will know (it
>>> may even be a know issue or gotcha). First off, the quick fix. This
>>> query (and variations like load(), get(), and using the criteria api)
>>> cause the problem:
>>>
>>> Listing listing = (Listing)session.createQuery("from Listing lst
>>> where lst.id=:id")
>>> .setLong("id", Long.valueOf(sListingId)).uniqueResult();
>>>
>>> This works as expected:
>>>
>>> Listing listing = (Listing)session.createQuery("from Listing lst
>>> where lst.id=" + sListingId)
>>> .uniqueResult();
>>>
>>> It seems to come down to how hibernate handles the query results when
>>> the query is formed with a "raw" HQL string vs something like get(),
>>> load(), the criteria api, or using query parameters as I was initially
>>> doing. It also has something to do with the field being queried and
>>> seems to happen only on fields that exist in each of the tables. In my
>>> case the abstract super class Listing has the PK field "id", and the 2
>>> subclasses also have a PK field named "id." Querying by any method other
>>> than "constructed strings" leads to the issue, while querying on another
>>> field in the super class, whose name is unique to that class, works fine.
>>>
>>> So the BIG question is why in the world does it work the first time and
>>> continue to work until the value one queries by changes?
>>>
>>> I'd also like to know if anyone has seen this before, and/or if it's a
>>> known issue. I'm using a slightly outdated version of hibernate
>>> (3.2.2.ga) and for all I know this may be fixed in more recent versions.
>>> My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
>>> interested/bored enough to try it, please let me know.
>>>
>>> Thanks tons for all of your input.
>>>
>>> Sincerely,
>>> Chris Lewis
>>>
>>> Chris Lewis 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
>>>>
>>>>
>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by Martijn Brinkers <m....@gmail.com>.
This posting also report similar problems and it was 'solved' by
disabling the statement cache.
https://jira.jboss.org/jira/browse/JBPORTAL-1287
Martijn
On Thu, 2008-07-24 at 22:57 -0700, Martijn Brinkers (List) wrote:
> Sounds to me something related to the PreparedStatement cache. Do you
> use c3po? If so did you specify hibernate.c3p0.max_statements?
>
> Martijn
>
>
> On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
> > Ok, I've figured out what exactly is causing it and how to work around
> > it. I can't say why, but perhaps a resident hibernate guru will know (it
> > may even be a know issue or gotcha). First off, the quick fix. This
> > query (and variations like load(), get(), and using the criteria api)
> > cause the problem:
> >
> > Listing listing = (Listing)session.createQuery("from Listing lst
> > where lst.id=:id")
> > .setLong("id", Long.valueOf(sListingId)).uniqueResult();
> >
> > This works as expected:
> >
> > Listing listing = (Listing)session.createQuery("from Listing lst
> > where lst.id=" + sListingId)
> > .uniqueResult();
> >
> > It seems to come down to how hibernate handles the query results when
> > the query is formed with a "raw" HQL string vs something like get(),
> > load(), the criteria api, or using query parameters as I was initially
> > doing. It also has something to do with the field being queried and
> > seems to happen only on fields that exist in each of the tables. In my
> > case the abstract super class Listing has the PK field "id", and the 2
> > subclasses also have a PK field named "id." Querying by any method other
> > than "constructed strings" leads to the issue, while querying on another
> > field in the super class, whose name is unique to that class, works fine.
> >
> > So the BIG question is why in the world does it work the first time and
> > continue to work until the value one queries by changes?
> >
> > I'd also like to know if anyone has seen this before, and/or if it's a
> > known issue. I'm using a slightly outdated version of hibernate
> > (3.2.2.ga) and for all I know this may be fixed in more recent versions.
> > My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
> > interested/bored enough to try it, please let me know.
> >
> > Thanks tons for all of your input.
> >
> > Sincerely,
> > Chris Lewis
> >
> > Chris Lewis 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
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
Session
Posted by "Martijn Brinkers (List)" <ma...@gmail.com>.
Sounds to me something related to the PreparedStatement cache. Do you
use c3po? If so did you specify hibernate.c3p0.max_statements?
Martijn
On Thu, 2008-07-24 at 23:26 -0400, Chris Lewis wrote:
> Ok, I've figured out what exactly is causing it and how to work around
> it. I can't say why, but perhaps a resident hibernate guru will know (it
> may even be a know issue or gotcha). First off, the quick fix. This
> query (and variations like load(), get(), and using the criteria api)
> cause the problem:
>
> Listing listing = (Listing)session.createQuery("from Listing lst
> where lst.id=:id")
> .setLong("id", Long.valueOf(sListingId)).uniqueResult();
>
> This works as expected:
>
> Listing listing = (Listing)session.createQuery("from Listing lst
> where lst.id=" + sListingId)
> .uniqueResult();
>
> It seems to come down to how hibernate handles the query results when
> the query is formed with a "raw" HQL string vs something like get(),
> load(), the criteria api, or using query parameters as I was initially
> doing. It also has something to do with the field being queried and
> seems to happen only on fields that exist in each of the tables. In my
> case the abstract super class Listing has the PK field "id", and the 2
> subclasses also have a PK field named "id." Querying by any method other
> than "constructed strings" leads to the issue, while querying on another
> field in the super class, whose name is unique to that class, works fine.
>
> So the BIG question is why in the world does it work the first time and
> continue to work until the value one queries by changes?
>
> I'd also like to know if anyone has seen this before, and/or if it's a
> known issue. I'm using a slightly outdated version of hibernate
> (3.2.2.ga) and for all I know this may be fixed in more recent versions.
> My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
> interested/bored enough to try it, please let me know.
>
> Thanks tons for all of your input.
>
> Sincerely,
> Chris Lewis
>
> Chris Lewis 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
Ok, I've figured out what exactly is causing it and how to work around
it. I can't say why, but perhaps a resident hibernate guru will know (it
may even be a know issue or gotcha). First off, the quick fix. This
query (and variations like load(), get(), and using the criteria api)
cause the problem:
Listing listing = (Listing)session.createQuery("from Listing lst
where lst.id=:id")
.setLong("id", Long.valueOf(sListingId)).uniqueResult();
This works as expected:
Listing listing = (Listing)session.createQuery("from Listing lst
where lst.id=" + sListingId)
.uniqueResult();
It seems to come down to how hibernate handles the query results when
the query is formed with a "raw" HQL string vs something like get(),
load(), the criteria api, or using query parameters as I was initially
doing. It also has something to do with the field being queried and
seems to happen only on fields that exist in each of the tables. In my
case the abstract super class Listing has the PK field "id", and the 2
subclasses also have a PK field named "id." Querying by any method other
than "constructed strings" leads to the issue, while querying on another
field in the super class, whose name is unique to that class, works fine.
So the BIG question is why in the world does it work the first time and
continue to work until the value one queries by changes?
I'd also like to know if anyone has seen this before, and/or if it's a
known issue. I'm using a slightly outdated version of hibernate
(3.2.2.ga) and for all I know this may be fixed in more recent versions.
My wrists are shot so I'll try tomorrow. If anyone knows of this or gets
interested/bored enough to try it, please let me know.
Thanks tons for all of your input.
Sincerely,
Chris Lewis
Chris Lewis 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Jonathan Barker <jo...@gmail.com>.
Making listing non-abstract "offends my sensibilities" but I occasionally
need to offend myself.
1) I've actually never tried. I did run into problems when joining two
hierarchies via a third relationship hierarchy. (Take two classes related by
an association where there are additional properties on the relation -
making it a class. Now subclass everything.) Hibernate worked
inconsistently as well. I didn't delve far enough to elicit a pattern, but
it might be related.
2) Strange, I know. The inconsistency I experienced was in a T5 project,
but I was executing it in a command-line utility class with Spring for
wiring things together. I don't think your problem is T5-specific.
3) I've never had a problem with objects fetched via associations.
As a test, is there an association you can leverage? Like "select au, li
from Author au join au.listings li where li.id = ?"
Then just ignore Author or whatever else you fetch?
Perhaps a guru on the Hibernate list can help.
> -----Original Message-----
> From: Chris Lewis [mailto:chris_lewis@bellsouth.net]
> Sent: Thursday, July 24, 2008 17:43
> To: Tapestry users
> Subject: Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a
> Session
>
> 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:chris_lewis@bellsouth.net]
> >> 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:chris_lewis@bellsouth.net]
> >>>> 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:chris_lewis@bellsouth.net]
> >>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> ------------------------------------------------------------------
> --
> >>>>>>>
> >> -
> >>
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> http://thegodcode.net
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --------------------------------------------------------------------
> -
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> http://thegodcode.net
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>>
> >> --
> >> http://thegodcode.net
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
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:chris_lewis@bellsouth.net]
>> 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:chris_lewis@bellsouth.net]
>>>> 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:chris_lewis@bellsouth.net]
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>> -
>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> http://thegodcode.net
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> http://thegodcode.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>> --
>> http://thegodcode.net
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
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:chris_lewis@bellsouth.net]
>> 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:chris_lewis@bellsouth.net]
>>>> 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:chris_lewis@bellsouth.net]
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>> -
>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> http://thegodcode.net
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> http://thegodcode.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>> --
>> http://thegodcode.net
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
RE: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Jonathan Barker <jo...@gmail.com>.
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:chris_lewis@bellsouth.net]
> 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:chris_lewis@bellsouth.net]
> >> 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:chris_lewis@bellsouth.net]
> >>>> 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
> >>>>>
> >>>>>
> >>>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> >>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> --------------------------------------------------------------------
> -
> >>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> http://thegodcode.net
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>>
> >> --
> >> http://thegodcode.net
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
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:chris_lewis@bellsouth.net]
>> 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:chris_lewis@bellsouth.net]
>>>> 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
>>>>>
>>>>>
>>>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> http://thegodcode.net
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>> --
>> http://thegodcode.net
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
RE: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Jonathan Barker <jo...@gmail.com>.
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:chris_lewis@bellsouth.net]
> 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:chris_lewis@bellsouth.net]
> >> 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
> >>>
> >> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> >>>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>>
> >>>>
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>>
> >> --
> >> http://thegodcode.net
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
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:chris_lewis@bellsouth.net]
>> 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
>>>
>> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>>
>> --
>> http://thegodcode.net
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
RE: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Jonathan Barker <jo...@gmail.com>.
Post your query and load code.
> -----Original Message-----
> From: Chris Lewis [mailto:chris_lewis@bellsouth.net]
> 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
> <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> http://thegodcode.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Chris Lewis <ch...@bellsouth.net>.
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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
http://thegodcode.net
Re: T5.0.14-SNAPSHOT: strange behavior Dispatcher when using a Session
Posted by Yunhua Sang <yu...@gmail.com>.
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 <ch...@bellsouth.net> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org