Re: T5: possible to get the 'real' object instead of a proxy?
just inject the HibernateSessionSource service and call create(); this call will delgate to Hibernate's SessionFactory and call openSession() that returns a Hibernate Session. then you have a real Hibernate Session instance and you can do whatever you want with it. and it does not have any dependencies to Tapestry IOC. then you'd have to deal with the session as described in the Hibernate documentation. i don't know exactly what your problem is... Tapestry-Hibernate will give you a per-thread Session anyway.. if you inject Session. g, kris Britske <[EMAIL PROTECTED]> 12.07.2008 00:59 Bitte antworten an "Tapestry users" An users@tapestry.apache.org Kopie Thema Re: T5: possible to get the 'real' object instead of a proxy? Would there be a way to both get 1. the real session object 2. the session object belonging to to current thread at the same time? Howard Lewis Ship wrote: > > No, this is the actual Hibernate Session object; you'll have to be > careful if you share it around between threads, or hold onto it after > the end of the current request. > > On Fri, Jul 11, 2008 at 11:04 AM, Britske <[EMAIL PROTECTED]> wrote: >> >> and this would also give me a session bound to the current thread? Like, >> I >> would inject in into a custom singleton service, and invoke the >> getSession-method from different threads. >> >> Would I still get the session bound to the current-thread or the session >> bound to the thread which first invoked getSession? >> >> >> >> >> Howard Lewis Ship wrote: >>> >>> The injectable Session object is a property shadow of >>> HibernateSessionManager.session. >>> >>> In other words, inject HibernateSessionManager, invoke getSession(). >>> >>> On Fri, Jul 11, 2008 at 4:57 AM, Filip S. Adamsen <[EMAIL PROTECTED]> >>> wrote: >>>> Hi, >>>> >>>> The problem here is that the proxy generated by Tapestry doesn't >>>> implement >>>> SessionImplementor. You'll have to get the SessionFactory and grab a >>>> Session >>>> from there if you want to do this. >>>> >>>> I don't use tapestry-hibernate so that's all I can say about that. >>>> >>>> By the way, the Session/SessionImplementor interfaces and the way >>>> they're >>>> used isn't bad design - it's exactly what interfaces are for. :) >>>> >>>> -Filip >>>> >>>> Britske skrev: >>>>> >>>>> When injecting a (hibernate) Session a proxy to the actual session is >>>>> returned. >>>>> However, when using the session in a lot of my dao-services I need to >>>>> have >>>>> access to the 'real' underlying session instead of just the proxy. >>>>> Is there a way to do this? >>>>> >>>>> Some background: after revisioning my dao/repository layer a bit I >>>>> want >>>>> to rely on >>>>> hibernate's DetachedCriteria for a lot of queries. THis basically >>>>> enables >>>>> you to build hibernate criteria's without having a session handy. >>>>> (very >>>>> useful in the light of MVC, etc. ) However, when actually executing >>>>> these >>>>> detachedcriteria through detachedcrit.getExecutableCriteria(Session >>>>> session) >>>>> a 'real' session has to be supplied since the method makes uses the >>>>> underlying implementation instead of just the session-interface. (bad >>>>> design, I know) >>>>> >>>>> Anyone? >>>> >>>> - >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>>> For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator Apache Tapestry and Apache HiveMind >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18409476.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18413975.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
Would there be a way to both get 1. the real session object 2. the session object belonging to to current thread at the same time? Howard Lewis Ship wrote: > > No, this is the actual Hibernate Session object; you'll have to be > careful if you share it around between threads, or hold onto it after > the end of the current request. > > On Fri, Jul 11, 2008 at 11:04 AM, Britske <[EMAIL PROTECTED]> wrote: >> >> and this would also give me a session bound to the current thread? Like, >> I >> would inject in into a custom singleton service, and invoke the >> getSession-method from different threads. >> >> Would I still get the session bound to the current-thread or the session >> bound to the thread which first invoked getSession? >> >> >> >> >> Howard Lewis Ship wrote: >>> >>> The injectable Session object is a property shadow of >>> HibernateSessionManager.session. >>> >>> In other words, inject HibernateSessionManager, invoke getSession(). >>> >>> On Fri, Jul 11, 2008 at 4:57 AM, Filip S. Adamsen <[EMAIL PROTECTED]> >>> wrote: Hi, The problem here is that the proxy generated by Tapestry doesn't implement SessionImplementor. You'll have to get the SessionFactory and grab a Session from there if you want to do this. I don't use tapestry-hibernate so that's all I can say about that. By the way, the Session/SessionImplementor interfaces and the way they're used isn't bad design - it's exactly what interfaces are for. :) -Filip Britske skrev: > > When injecting a (hibernate) Session a proxy to the actual session is > returned. > However, when using the session in a lot of my dao-services I need to > have > access to the 'real' underlying session instead of just the proxy. > Is there a way to do this? > > Some background: after revisioning my dao/repository layer a bit I > want > to rely on > hibernate's DetachedCriteria for a lot of queries. THis basically > enables > you to build hibernate criteria's without having a session handy. > (very > useful in the light of MVC, etc. ) However, when actually executing > these > detachedcriteria through detachedcrit.getExecutableCriteria(Session > session) > a 'real' session has to be supplied since the method makes uses the > underlying implementation instead of just the session-interface. (bad > design, I know) > > Anyone? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> -- >>> Howard M. Lewis Ship >>> >>> Creator Apache Tapestry and Apache HiveMind >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18409476.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18413975.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
I meant that the hibernate-implementation is bad design here. Having a method: getExecutableCriteria(Session session) to me would mean that any object adhering to the interface Session could be passed as a parameter. However getExecutableCriteria really needs a SessionImpl to be passed so that should have been the type of the param. Filip S. Adamsen-2 wrote: > > Hi, > > The problem here is that the proxy generated by Tapestry doesn't > implement SessionImplementor. You'll have to get the SessionFactory and > grab a Session from there if you want to do this. > > I don't use tapestry-hibernate so that's all I can say about that. > > By the way, the Session/SessionImplementor interfaces and the way > they're used isn't bad design - it's exactly what interfaces are for. :) > > -Filip > > Britske skrev: >> When injecting a (hibernate) Session a proxy to the actual session is >> returned. >> >> However, when using the session in a lot of my dao-services I need to >> have >> access to the 'real' underlying session instead of just the proxy. >> >> Is there a way to do this? >> >> >> Some background: >> after revisioning my dao/repository layer a bit I want to rely on >> hibernate's DetachedCriteria for a lot of queries. THis basically enables >> you to build hibernate criteria's without having a session handy. (very >> useful in the light of MVC, etc. ) However, when actually executing these >> detachedcriteria through detachedcrit.getExecutableCriteria(Session >> session) >> a 'real' session has to be supplied since the method makes uses the >> underlying implementation instead of just the session-interface. (bad >> design, I know) >> >> Anyone? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18409536.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
No, this is the actual Hibernate Session object; you'll have to be careful if you share it around between threads, or hold onto it after the end of the current request. On Fri, Jul 11, 2008 at 11:04 AM, Britske <[EMAIL PROTECTED]> wrote: > > and this would also give me a session bound to the current thread? Like, I > would inject in into a custom singleton service, and invoke the > getSession-method from different threads. > > Would I still get the session bound to the current-thread or the session > bound to the thread which first invoked getSession? > > > > > Howard Lewis Ship wrote: >> >> The injectable Session object is a property shadow of >> HibernateSessionManager.session. >> >> In other words, inject HibernateSessionManager, invoke getSession(). >> >> On Fri, Jul 11, 2008 at 4:57 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> The problem here is that the proxy generated by Tapestry doesn't >>> implement >>> SessionImplementor. You'll have to get the SessionFactory and grab a >>> Session >>> from there if you want to do this. >>> >>> I don't use tapestry-hibernate so that's all I can say about that. >>> >>> By the way, the Session/SessionImplementor interfaces and the way they're >>> used isn't bad design - it's exactly what interfaces are for. :) >>> >>> -Filip >>> >>> Britske skrev: When injecting a (hibernate) Session a proxy to the actual session is returned. However, when using the session in a lot of my dao-services I need to have access to the 'real' underlying session instead of just the proxy. Is there a way to do this? Some background: after revisioning my dao/repository layer a bit I want to rely on hibernate's DetachedCriteria for a lot of queries. THis basically enables you to build hibernate criteria's without having a session handy. (very useful in the light of MVC, etc. ) However, when actually executing these detachedcriteria through detachedcrit.getExecutableCriteria(Session session) a 'real' session has to be supplied since the method makes uses the underlying implementation instead of just the session-interface. (bad design, I know) Anyone? >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> >> -- >> Howard M. Lewis Ship >> >> Creator Apache Tapestry and Apache HiveMind >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- > View this message in context: > http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18409476.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
and this would also give me a session bound to the current thread? Like, I would inject in into a custom singleton service, and invoke the getSession-method from different threads. Would I still get the session bound to the current-thread or the session bound to the thread which first invoked getSession? Howard Lewis Ship wrote: > > The injectable Session object is a property shadow of > HibernateSessionManager.session. > > In other words, inject HibernateSessionManager, invoke getSession(). > > On Fri, Jul 11, 2008 at 4:57 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: >> Hi, >> >> The problem here is that the proxy generated by Tapestry doesn't >> implement >> SessionImplementor. You'll have to get the SessionFactory and grab a >> Session >> from there if you want to do this. >> >> I don't use tapestry-hibernate so that's all I can say about that. >> >> By the way, the Session/SessionImplementor interfaces and the way they're >> used isn't bad design - it's exactly what interfaces are for. :) >> >> -Filip >> >> Britske skrev: >>> >>> When injecting a (hibernate) Session a proxy to the actual session is >>> returned. >>> However, when using the session in a lot of my dao-services I need to >>> have >>> access to the 'real' underlying session instead of just the proxy. >>> Is there a way to do this? >>> >>> Some background: after revisioning my dao/repository layer a bit I want >>> to rely on >>> hibernate's DetachedCriteria for a lot of queries. THis basically >>> enables >>> you to build hibernate criteria's without having a session handy. (very >>> useful in the light of MVC, etc. ) However, when actually executing >>> these >>> detachedcriteria through detachedcrit.getExecutableCriteria(Session >>> session) >>> a 'real' session has to be supplied since the method makes uses the >>> underlying implementation instead of just the session-interface. (bad >>> design, I know) >>> >>> Anyone? >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/T5%3A-possible-to-get-the-%27real%27-object-instead-of-a-proxy--tp18400135p18409476.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
The injectable Session object is a property shadow of HibernateSessionManager.session. In other words, inject HibernateSessionManager, invoke getSession(). On Fri, Jul 11, 2008 at 4:57 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote: > Hi, > > The problem here is that the proxy generated by Tapestry doesn't implement > SessionImplementor. You'll have to get the SessionFactory and grab a Session > from there if you want to do this. > > I don't use tapestry-hibernate so that's all I can say about that. > > By the way, the Session/SessionImplementor interfaces and the way they're > used isn't bad design - it's exactly what interfaces are for. :) > > -Filip > > Britske skrev: >> >> When injecting a (hibernate) Session a proxy to the actual session is >> returned. >> However, when using the session in a lot of my dao-services I need to have >> access to the 'real' underlying session instead of just the proxy. >> Is there a way to do this? >> >> Some background: after revisioning my dao/repository layer a bit I want >> to rely on >> hibernate's DetachedCriteria for a lot of queries. THis basically enables >> you to build hibernate criteria's without having a session handy. (very >> useful in the light of MVC, etc. ) However, when actually executing these >> detachedcriteria through detachedcrit.getExecutableCriteria(Session >> session) >> a 'real' session has to be supplied since the method makes uses the >> underlying implementation instead of just the session-interface. (bad >> design, I know) >> >> Anyone? > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5: possible to get the 'real' object instead of a proxy?
Hi, The problem here is that the proxy generated by Tapestry doesn't implement SessionImplementor. You'll have to get the SessionFactory and grab a Session from there if you want to do this. I don't use tapestry-hibernate so that's all I can say about that. By the way, the Session/SessionImplementor interfaces and the way they're used isn't bad design - it's exactly what interfaces are for. :) -Filip Britske skrev: When injecting a (hibernate) Session a proxy to the actual session is returned. However, when using the session in a lot of my dao-services I need to have access to the 'real' underlying session instead of just the proxy. Is there a way to do this? Some background: after revisioning my dao/repository layer a bit I want to rely on hibernate's DetachedCriteria for a lot of queries. THis basically enables you to build hibernate criteria's without having a session handy. (very useful in the light of MVC, etc. ) However, when actually executing these detachedcriteria through detachedcrit.getExecutableCriteria(Session session) a 'real' session has to be supplied since the method makes uses the underlying implementation instead of just the session-interface. (bad design, I know) Anyone? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
