On mine it's : <filter-mapping> <filter-name>OpenSessionInViewFilter</filter-name> <url-pattern>*.ajax</url-pattern> </filter-mapping>
I don't recall if .ajax is the default or if that's something I modified. In any case you can lookup what URL is actually being used in your request and make sure it matches that. On 11/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
great, thanks , this must be the reason. How do you define it? Like <url-pattern>*ajaxdirect.svc*</url-pattern> ? ----- Original Message ----- From: "Daniel Tabuenca" <[EMAIL PROTECTED]> To: "Tapestry users" <users@tapestry.apache.org> Sent: Sunday, November 05, 2006 16:35 Subject: Re: Tapestry-Hibernate >A tacos asynchronous requests is still a standard request as far as > the servlet is concenred. What is not working for you? I have used > this same exact setup using a slightly modified version of Spring's > OpenSessionInView filter and it works fine. Make sure you are using a > filter-mapping that matches the urls used for tacos' ajax-direct > service not just the normal Tapestry urls. > > On 11/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Hi, >> >> I am using Hibernate+Spring+Tapestry and Spring's OpenSessionInView >> filter. >> It works fine with classical Http Requests. But it does not work with >> asynchronous requests i.e. with tacos, perhaps now with tapestry 4.1. If >> you >> have any ideas how to make it work i am interested. >> >> >> >> ----- Original Message ----- >> From: "Bill Holloway" <[EMAIL PROTECTED]> >> To: "Tapestry users" <users@tapestry.apache.org> >> Sent: Sunday, November 05, 2006 08:52 >> Subject: Re: Tapestry-Hibernate >> >> >> >I don't know about reconnecting the object in session-per-request. >> > The session is not maintained between requests. I think that's >> > session-per-conversation. There a version number column for the >> > database entity that increments on the first entity select. If the >> > version number doesn't match, a warning is raised...if I'm >> > understanding hibernate properly. >> > >> > Cheers, >> > >> > Bill >> > >> > On 11/4/06, Daniel Tabuenca <[EMAIL PROTECTED]> wrote: >> >> So do you have some way of locking all objects to the new session on >> >> the subsequent request? Is this automated in some way? My problem with >> >> the session-per-request-with-detached-objects is that there needs to >> >> be some way to easily identify and re-attach the set of objects that >> >> will be used. I've found it easiest to just keep the session and >> >> reconnect it to the database on the new request. The one problem with >> >> this is if you conversation is long your session might grow too big >> >> since things are not cleaned out of the session even if you >> >> application does not hold any additional references. Maybe ideally it >> >> would be to use some form of AOP to automatically lock objects to the >> >> new session on demand. This seems like it'd be awfully useful, though >> >> I'm not sure how feasible it is to implement. >> >> >> >> On 11/4/06, Bill Holloway <[EMAIL PROTECTED]> wrote: >> >> > For the lazy loading, what about writing a custom servlet filter as >> >> > recommended in the hibernate docs, one that handles the session for >> >> > you? Let it sit out there in front of Tapestry and manage the >> >> > sessions. I'm leaning toward >> >> > session-per-request-with-detached-objects and letting optimistic >> >> > locking handle the concurrency issues. I'm not so concerned about >> >> > that issue. >> >> > >> >> > My real issue is with the lazy-loading. We'll have objects with >> >> > some >> >> > pretty hefty fields -- text and maybe blob types -- that I REALLY >> >> > don't want to have loaded if I don't have to. >> >> > >> >> > Cheers, >> >> > Bill >> >> > >> >> > On 11/4/06, James Carman <[EMAIL PROTECTED]> wrote: >> >> > > Bill, >> >> > > >> >> > > The lazy loading problem can't really be solved in a generalized >> >> > > way. >> >> > > But, Tapernate does a lot of work for you. I wouldn't suggest >> >> > > using >> >> > > the property persistence strategies from Tapernate right now. I'm >> >> > > working on a new version that will hopefully be more robust. The >> >> > > main >> >> > > problem that I face is knowing exactly *how* to reattach the >> >> > > detached >> >> > > object to the session when a request comes in. There are a few >> >> > > different scenarios and the problem is knowing which one you're >> >> > > in! >> >> > > Also, if you use merge or update, then your object's state will be >> >> > > persisted at the end of the request (assuming that you leave >> >> > > transaction-per-request on). What if you don't really want the >> >> > > state >> >> > > persisted during that request (you're in the middle of a "wizard" >> >> > > perhaps)? I think the way to go is to use the >> >> > > session-per-conversation pattern, but I'm trying to come up with a >> >> > > good way to specify conversation boundaries. Also, should we >> >> > > support >> >> > > more than one conversation at a time (what if the user clicks to >> >> > > go >> >> > > to >> >> > > another part of your webapp from within your wizard)? If so, how >> >> > > do >> >> > > the potentially orphaned conversations get cleaned up? This is >> >> > > what >> >> > > causes me to loose sleep at night (yes, I need a life). :-) >> >> > > >> >> > > >> >> > > >> >> > > On 11/3/06, Bill Holloway <[EMAIL PROTECTED]> wrote: >> >> > > > I've seen recently some criticism of Tapestry in terms of using >> >> > > > Hibernate. Problems with lazy loading. I know Tapernate is out >> >> > > > there, but the docs are pretty thin. I'm using the threadLocal >> >> > > > version of the much-documented HibernateUtil in a DAO layer. >> >> > > > Going >> >> > > > well. What will Tapernate actually do for me? Does it really >> >> > > > solve >> >> > > > the lazy-loading problem? Are there decent docs? >> >> > > > >> >> > > > I would HATE to have to abandon tapestry to work around >> >> > > > performance >> >> > > > problems falling out of non-lazy-loading. >> >> > > > >> >> > > > Thanks, >> >> > > > Bill >> >> > > > >> >> > > > --------------------------------------------------------------------- >> >> > > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > > > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > >> >> > > > >> >> > > >> >> > > --------------------------------------------------------------------- >> >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > >> >> > > >> >> > >> >> > >> >> > -- >> >> > "Budgets are moral documents." >> >> > >> >> > -- Ann Richards >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >> >> > >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> > -- >> > "Budgets are moral documents." >> > >> > -- Ann Richards >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
