You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ralph Churchill <mr...@gmail.com> on 2005/12/12 19:57:07 UTC
Tapestry4 setupForRequest "replacement"?
In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
DataSource from JNDI, open a Connection from it and make the Connection
accessible via static methods to my DAO classes. I closed Connection via
overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC -- no
Hibernate, Spring, etc.
This simple scheme has worked very well so far.
I'm looking for an equivalent in Tapestry4. I have seen this sort of
question posed numerous times, but not sufficiently answered. I'm wondering,
what is the best way to implement functionality similar to this? I have some
ideas: using RequestGlobals, injecting a service with a "request" or
"thread" scope, etc.
Please note: for my configuration, a servlet filter is not a viable option.
Thanks.
RMC
Re: Tapestry4 setupForRequest "replacement"?
Posted by Geoff Longman <gl...@gmail.com>.
Howabout a servlet filter?
Geoff
On 12/12/05, Ralph Churchill <mr...@gmail.com> wrote:
> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> DataSource from JNDI, open a Connection from it and make the Connection
> accessible via static methods to my DAO classes. I closed Connection via
> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC -- no
> Hibernate, Spring, etc.
>
> This simple scheme has worked very well so far.
>
> I'm looking for an equivalent in Tapestry4. I have seen this sort of
> question posed numerous times, but not sufficiently answered. I'm wondering,
> what is the best way to implement functionality similar to this? I have some
> ideas: using RequestGlobals, injecting a service with a "request" or
> "thread" scope, etc.
>
> Please note: for my configuration, a servlet filter is not a viable option.
> Thanks.
>
> RMC
>
>
--
The Spindle guy. http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Announcement Feed:
http://www.jroller.com/rss/glongman?catname=/Announcements
Feature Updates: http://spindle.sf.net/updates
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Raul Raja Martinez <do...@estudiowebs.com>.
Try taking a look at
http://hivetranse.sourceforge.net/quickstart.html#start.config.jdbc
Hivemind utilities either with jdbc or hibernate3 might be your solution.
best regards.
Raul.
Ralph Churchill wrote:
> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> DataSource from JNDI, open a Connection from it and make the Connection
> accessible via static methods to my DAO classes. I closed Connection via
> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC -- no
> Hibernate, Spring, etc.
>
> This simple scheme has worked very well so far.
>
> I'm looking for an equivalent in Tapestry4. I have seen this sort of
> question posed numerous times, but not sufficiently answered. I'm wondering,
> what is the best way to implement functionality similar to this? I have some
> ideas: using RequestGlobals, injecting a service with a "request" or
> "thread" scope, etc.
>
> Please note: for my configuration, a servlet filter is not a viable option.
> Thanks.
>
> RMC
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ralph Churchill <mr...@gmail.com>.
That works great! Thanks for all the help. I'm almost starting to like all
this new Hivemind stuff ;)
RMC
p.s. actually it makes a great deal of sense
On 12/14/05, Ron Piterman <rp...@gmx.net> wrote:
>
> I have an improvement for you :)
> if you add an interface to your service point "ConnectionProxy", say A,
> *and* your class MyController exposes a public class "setXXX(A)" *and*
> hivemind does have only *one* service point of interface A, it will be
> autowired to MyController: hivemind will call setXXX(a), where a is the
> service ConnectionProxy, constructed by hivemind.
>
> So, you can have a bunch of different services, and if each one is
> defined by a unique interface, all you need is (love) expose in your
> implementation class a set method, and hivemind does the work. no need
> to <set-object>...
>
> that makes thing alot easier when you have more than 2 services and many
> dependencies. you don't have to <set-object> for each dependency, but
> make sure the service-pont-interface is unique.
>
>
> Ralph Churchill wrote:
> > I think I have a solution, but it still seems a little cumbersome.
> >
> > Each of my pages already delegates its business logic to a "controller"
> > class. The "controller" classes, in turn, use DAOs. So, in each page I
> > <inject> a controller as a property and use a hivemind service:
> >
> > <inject property="homeController" object="service:Controller"/>
> >
> > I define the controller service point, like so and give it another
> property,
> > "connection":
> >
> > <service-point id="Controller">
> > <invoke-factory>
> > <construct class="MyController">
> > <set-object property="connection"
> > value="service:ConnectionProxy"/>
> > </construct>
> > </invoke-factory>
> > </service-point>
> >
> > <service-point id="ConnectionProxy">
> > <invoke-factory model="threaded">
> > <construct class="MyConnectionProxy"/>
> > </invoke-factory>
> > </service-point>
> >
> > This works great! Is this an acceptable way to do things? The only issue
> I
> > have is that I have to create an unnecessary interface, "Controller",
> for
> > each page's controller class. Any comments/suggestions?
> >
> > RMC
> >
> > On 12/13/05, Ralph Churchill <mr...@gmail.com> wrote:
> >
> >>Are you talk about this article?
> >>
> >>http://www.theserverside.com/articles/article.tss?l=HivemindBuzz
> >>
> >>Thanks.
> >>
> >>RMC
> >>
> >>On 12/13/05, Ron Piterman <rp...@gmx.net> wrote:
> >>
> >>>Didier LAFFORGUE wrote:
> >>>
> >>>>In Tapestry 3.0.3, I had a simple way to get a connection for each
> >>>>request: all my pages extended a special page (implementing
> >>>>PageRenderListener) which did some stuffs as: check the if the current
> >>>
> >>>>user was authentified, ...etc and open a connection !
> >>>>The code:
> >>>>
> >>>>/** The special Page */
> >>>>public class SpecialPage extends BasePage implements
> >>>>PageValidateListener, PageRenderListener {
> >>>> ...
> >>>> public void pageBeginRender(PageEvent event) {
> >>>> // open a new connection
> >>>> }
> >>>>
> >>>> public void pageEndRender(PageEvent event) {
> >>>> // close the connection
> >>>> }
> >>>>}
> >>>>
> >>>>public class MyPage extends SpecialPage {
> >>>>
> >>>>
> >>>>}
> >>>>
> >>>>I think this solution is not the best in Tapestry 4.0 but it must
> >>>
> >>>work.
> >>>
> >>>>The big problem is that you have to refactor all your existing pages
> >>>
> >>>to
> >>>
> >>>>extend SpecialPage.
> >>>
> >>>Read thoroughly (does it spell like that?) the article about hivemind
> in
> >>>'the server side'. There is an example there for just what you are
> >>>trying to do.
> >>>In Tapestry 4 you use a services layer approach, which, imo, is *much*
> >>>better then solving this in the UI layer, like you did in 3. It
> >>>seperates concerns and is, in end effect, much better to work with.
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>>----- Original Message ----- From: "Ron Piterman" < rpiterman@gmx.net>
> >>>>To: <ta...@jakarta.apache.org>
> >>>>Sent: Tuesday, December 13, 2005 1:23 AM
> >>>>Subject: Re: Tapestry4 setupForRequest "replacement"?
> >>>>
> >>>>
> >>>>
> >>>>>what about wrapping an object around your initialization and using it
> >>>>>in a hivemind threaded model?
> >>>>>
> >>>>>Ralph Churchill wrote:
> >>>>>
> >>>>>
> >>>>>>In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> >>>>>>DataSource from JNDI, open a Connection from it and make the
> >>>
> >>>Connection
> >>>
> >>>>>>accessible via static methods to my DAO classes. I closed Connection
> >>>
> >>>via
> >>>
> >>>>>>overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC
> >>>
> >>>>>>-- no
> >>>>>>Hibernate, Spring, etc.
> >>>>>>
> >>>>>>This simple scheme has worked very well so far.
> >>>>>>
> >>>>>>I'm looking for an equivalent in Tapestry4. I have seen this sort of
> >>>
> >>>>>>question posed numerous times, but not sufficiently answered. I'm
> >>>>>>wondering,
> >>>>>>what is the best way to implement functionality similar to this? I
> >>>>>>have some
> >>>>>>ideas: using RequestGlobals, injecting a service with a "request" or
> >>>>>>"thread" scope, etc.
> >>>>>>
> >>>>>>Please note: for my configuration, a servlet filter is not a viable
> >>>>>>option.
> >>>>>>Thanks.
> >>>>>>
> >>>>>>RMC
> >>>>>>
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>>>>For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >>>
> >>>>
> >>>>
> >>>>This message contains information that may be privileged or
> >>>
> >>>confidential
> >>>
> >>>>and is the property of the Capgemini Group. It is intended only for
> >>>
> >>>the
> >>>
> >>>>person to whom it is addressed. If you are not the intended recipient,
> >>>
> >>>>you are not authorized to read, print, retain, copy, disseminate,
> >>>>distribute, or use this message or any part thereof. If you receive
> >>>>this message in error, please notify the sender immediately and
> >>>
> >>>delete
> >>>
> >>>>all copies of this message.
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ron Piterman <rp...@gmx.net>.
I have an improvement for you :)
if you add an interface to your service point "ConnectionProxy", say A,
*and* your class MyController exposes a public class "setXXX(A)" *and*
hivemind does have only *one* service point of interface A, it will be
autowired to MyController: hivemind will call setXXX(a), where a is the
service ConnectionProxy, constructed by hivemind.
So, you can have a bunch of different services, and if each one is
defined by a unique interface, all you need is (love) expose in your
implementation class a set method, and hivemind does the work. no need
to <set-object>...
that makes thing alot easier when you have more than 2 services and many
dependencies. you don't have to <set-object> for each dependency, but
make sure the service-pont-interface is unique.
Ralph Churchill wrote:
> I think I have a solution, but it still seems a little cumbersome.
>
> Each of my pages already delegates its business logic to a "controller"
> class. The "controller" classes, in turn, use DAOs. So, in each page I
> <inject> a controller as a property and use a hivemind service:
>
> <inject property="homeController" object="service:Controller"/>
>
> I define the controller service point, like so and give it another property,
> "connection":
>
> <service-point id="Controller">
> <invoke-factory>
> <construct class="MyController">
> <set-object property="connection"
> value="service:ConnectionProxy"/>
> </construct>
> </invoke-factory>
> </service-point>
>
> <service-point id="ConnectionProxy">
> <invoke-factory model="threaded">
> <construct class="MyConnectionProxy"/>
> </invoke-factory>
> </service-point>
>
> This works great! Is this an acceptable way to do things? The only issue I
> have is that I have to create an unnecessary interface, "Controller", for
> each page's controller class. Any comments/suggestions?
>
> RMC
>
> On 12/13/05, Ralph Churchill <mr...@gmail.com> wrote:
>
>>Are you talk about this article?
>>
>>http://www.theserverside.com/articles/article.tss?l=HivemindBuzz
>>
>>Thanks.
>>
>>RMC
>>
>>On 12/13/05, Ron Piterman <rp...@gmx.net> wrote:
>>
>>>Didier LAFFORGUE wrote:
>>>
>>>>In Tapestry 3.0.3, I had a simple way to get a connection for each
>>>>request: all my pages extended a special page (implementing
>>>>PageRenderListener) which did some stuffs as: check the if the current
>>>
>>>>user was authentified, ...etc and open a connection !
>>>>The code:
>>>>
>>>>/** The special Page */
>>>>public class SpecialPage extends BasePage implements
>>>>PageValidateListener, PageRenderListener {
>>>> ...
>>>> public void pageBeginRender(PageEvent event) {
>>>> // open a new connection
>>>> }
>>>>
>>>> public void pageEndRender(PageEvent event) {
>>>> // close the connection
>>>> }
>>>>}
>>>>
>>>>public class MyPage extends SpecialPage {
>>>>
>>>>
>>>>}
>>>>
>>>>I think this solution is not the best in Tapestry 4.0 but it must
>>>
>>>work.
>>>
>>>>The big problem is that you have to refactor all your existing pages
>>>
>>>to
>>>
>>>>extend SpecialPage.
>>>
>>>Read thoroughly (does it spell like that?) the article about hivemind in
>>>'the server side'. There is an example there for just what you are
>>>trying to do.
>>>In Tapestry 4 you use a services layer approach, which, imo, is *much*
>>>better then solving this in the UI layer, like you did in 3. It
>>>seperates concerns and is, in end effect, much better to work with.
>>>
>>>
>>>
>>>>
>>>>
>>>>----- Original Message ----- From: "Ron Piterman" < rpiterman@gmx.net>
>>>>To: <ta...@jakarta.apache.org>
>>>>Sent: Tuesday, December 13, 2005 1:23 AM
>>>>Subject: Re: Tapestry4 setupForRequest "replacement"?
>>>>
>>>>
>>>>
>>>>>what about wrapping an object around your initialization and using it
>>>>>in a hivemind threaded model?
>>>>>
>>>>>Ralph Churchill wrote:
>>>>>
>>>>>
>>>>>>In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
>>>>>>DataSource from JNDI, open a Connection from it and make the
>>>
>>>Connection
>>>
>>>>>>accessible via static methods to my DAO classes. I closed Connection
>>>
>>>via
>>>
>>>>>>overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC
>>>
>>>>>>-- no
>>>>>>Hibernate, Spring, etc.
>>>>>>
>>>>>>This simple scheme has worked very well so far.
>>>>>>
>>>>>>I'm looking for an equivalent in Tapestry4. I have seen this sort of
>>>
>>>>>>question posed numerous times, but not sufficiently answered. I'm
>>>>>>wondering,
>>>>>>what is the best way to implement functionality similar to this? I
>>>>>>have some
>>>>>>ideas: using RequestGlobals, injecting a service with a "request" or
>>>>>>"thread" scope, etc.
>>>>>>
>>>>>>Please note: for my configuration, a servlet filter is not a viable
>>>>>>option.
>>>>>>Thanks.
>>>>>>
>>>>>>RMC
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>>
>>>>
>>>>This message contains information that may be privileged or
>>>
>>>confidential
>>>
>>>>and is the property of the Capgemini Group. It is intended only for
>>>
>>>the
>>>
>>>>person to whom it is addressed. If you are not the intended recipient,
>>>
>>>>you are not authorized to read, print, retain, copy, disseminate,
>>>>distribute, or use this message or any part thereof. If you receive
>>>>this message in error, please notify the sender immediately and
>>>
>>>delete
>>>
>>>>all copies of this message.
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>>
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ralph Churchill <mr...@gmail.com>.
I think I have a solution, but it still seems a little cumbersome.
Each of my pages already delegates its business logic to a "controller"
class. The "controller" classes, in turn, use DAOs. So, in each page I
<inject> a controller as a property and use a hivemind service:
<inject property="homeController" object="service:Controller"/>
I define the controller service point, like so and give it another property,
"connection":
<service-point id="Controller">
<invoke-factory>
<construct class="MyController">
<set-object property="connection"
value="service:ConnectionProxy"/>
</construct>
</invoke-factory>
</service-point>
<service-point id="ConnectionProxy">
<invoke-factory model="threaded">
<construct class="MyConnectionProxy"/>
</invoke-factory>
</service-point>
This works great! Is this an acceptable way to do things? The only issue I
have is that I have to create an unnecessary interface, "Controller", for
each page's controller class. Any comments/suggestions?
RMC
On 12/13/05, Ralph Churchill <mr...@gmail.com> wrote:
>
> Are you talk about this article?
>
> http://www.theserverside.com/articles/article.tss?l=HivemindBuzz
>
> Thanks.
>
> RMC
>
> On 12/13/05, Ron Piterman <rp...@gmx.net> wrote:
> >
> > Didier LAFFORGUE wrote:
> > >
> > > In Tapestry 3.0.3, I had a simple way to get a connection for each
> > > request: all my pages extended a special page (implementing
> > > PageRenderListener) which did some stuffs as: check the if the current
> >
> > > user was authentified, ...etc and open a connection !
> > > The code:
> > >
> > > /** The special Page */
> > > public class SpecialPage extends BasePage implements
> > > PageValidateListener, PageRenderListener {
> > > ...
> > > public void pageBeginRender(PageEvent event) {
> > > // open a new connection
> > > }
> > >
> > > public void pageEndRender(PageEvent event) {
> > > // close the connection
> > > }
> > > }
> > >
> > > public class MyPage extends SpecialPage {
> > >
> > >
> > > }
> > >
> > > I think this solution is not the best in Tapestry 4.0 but it must
> > work.
> > > The big problem is that you have to refactor all your existing pages
> > to
> > > extend SpecialPage.
> >
> > Read thoroughly (does it spell like that?) the article about hivemind in
> > 'the server side'. There is an example there for just what you are
> > trying to do.
> > In Tapestry 4 you use a services layer approach, which, imo, is *much*
> > better then solving this in the UI layer, like you did in 3. It
> > seperates concerns and is, in end effect, much better to work with.
> >
> >
> > >
> > >
> > >
> > > ----- Original Message ----- From: "Ron Piterman" < rpiterman@gmx.net>
> > > To: <ta...@jakarta.apache.org>
> > > Sent: Tuesday, December 13, 2005 1:23 AM
> > > Subject: Re: Tapestry4 setupForRequest "replacement"?
> > >
> > >
> > >> what about wrapping an object around your initialization and using it
> > >> in a hivemind threaded model?
> > >>
> > >> Ralph Churchill wrote:
> > >>
> > >>> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> > >>> DataSource from JNDI, open a Connection from it and make the
> > Connection
> > >>> accessible via static methods to my DAO classes. I closed Connection
> > via
> > >>> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC
> >
> > >>> -- no
> > >>> Hibernate, Spring, etc.
> > >>>
> > >>> This simple scheme has worked very well so far.
> > >>>
> > >>> I'm looking for an equivalent in Tapestry4. I have seen this sort of
> >
> > >>> question posed numerous times, but not sufficiently answered. I'm
> > >>> wondering,
> > >>> what is the best way to implement functionality similar to this? I
> > >>> have some
> > >>> ideas: using RequestGlobals, injecting a service with a "request" or
> > >>> "thread" scope, etc.
> > >>>
> > >>> Please note: for my configuration, a servlet filter is not a viable
> > >>> option.
> > >>> Thanks.
> > >>>
> > >>> RMC
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > >> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> > >
> > >
> > >
> > > This message contains information that may be privileged or
> > confidential
> > > and is the property of the Capgemini Group. It is intended only for
> > the
> > > person to whom it is addressed. If you are not the intended recipient,
> >
> > > you are not authorized to read, print, retain, copy, disseminate,
> > > distribute, or use this message or any part thereof. If you receive
> > > this message in error, please notify the sender immediately and
> > delete
> > > all copies of this message.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ralph Churchill <mr...@gmail.com>.
Are you talk about this article?
http://www.theserverside.com/articles/article.tss?l=HivemindBuzz
Thanks.
RMC
On 12/13/05, Ron Piterman <rp...@gmx.net> wrote:
>
> Didier LAFFORGUE wrote:
> >
> > In Tapestry 3.0.3, I had a simple way to get a connection for each
> > request: all my pages extended a special page (implementing
> > PageRenderListener) which did some stuffs as: check the if the current
> > user was authentified, ...etc and open a connection !
> > The code:
> >
> > /** The special Page */
> > public class SpecialPage extends BasePage implements
> > PageValidateListener, PageRenderListener {
> > ...
> > public void pageBeginRender(PageEvent event) {
> > // open a new connection
> > }
> >
> > public void pageEndRender(PageEvent event) {
> > // close the connection
> > }
> > }
> >
> > public class MyPage extends SpecialPage {
> >
> >
> > }
> >
> > I think this solution is not the best in Tapestry 4.0 but it must work.
> > The big problem is that you have to refactor all your existing pages to
> > extend SpecialPage.
>
> Read thoroughly (does it spell like that?) the article about hivemind in
> 'the server side'. There is an example there for just what you are
> trying to do.
> In Tapestry 4 you use a services layer approach, which, imo, is *much*
> better then solving this in the UI layer, like you did in 3. It
> seperates concerns and is, in end effect, much better to work with.
>
>
> >
> >
> >
> > ----- Original Message ----- From: "Ron Piterman" <rp...@gmx.net>
> > To: <ta...@jakarta.apache.org>
> > Sent: Tuesday, December 13, 2005 1:23 AM
> > Subject: Re: Tapestry4 setupForRequest "replacement"?
> >
> >
> >> what about wrapping an object around your initialization and using it
> >> in a hivemind threaded model?
> >>
> >> Ralph Churchill wrote:
> >>
> >>> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> >>> DataSource from JNDI, open a Connection from it and make the
> Connection
> >>> accessible via static methods to my DAO classes. I closed Connection
> via
> >>> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC
> >>> -- no
> >>> Hibernate, Spring, etc.
> >>>
> >>> This simple scheme has worked very well so far.
> >>>
> >>> I'm looking for an equivalent in Tapestry4. I have seen this sort of
> >>> question posed numerous times, but not sufficiently answered. I'm
> >>> wondering,
> >>> what is the best way to implement functionality similar to this? I
> >>> have some
> >>> ideas: using RequestGlobals, injecting a service with a "request" or
> >>> "thread" scope, etc.
> >>>
> >>> Please note: for my configuration, a servlet filter is not a viable
> >>> option.
> >>> Thanks.
> >>>
> >>> RMC
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> > This message contains information that may be privileged or confidential
> > and is the property of the Capgemini Group. It is intended only for the
> > person to whom it is addressed. If you are not the intended recipient,
> > you are not authorized to read, print, retain, copy, disseminate,
> > distribute, or use this message or any part thereof. If you receive
> > this message in error, please notify the sender immediately and delete
> > all copies of this message.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ron Piterman <rp...@gmx.net>.
Didier LAFFORGUE wrote:
>
> In Tapestry 3.0.3, I had a simple way to get a connection for each
> request: all my pages extended a special page (implementing
> PageRenderListener) which did some stuffs as: check the if the current
> user was authentified, ...etc and open a connection !
> The code:
>
> /** The special Page */
> public class SpecialPage extends BasePage implements
> PageValidateListener, PageRenderListener {
> ...
> public void pageBeginRender(PageEvent event) {
> // open a new connection
> }
>
> public void pageEndRender(PageEvent event) {
> // close the connection
> }
> }
>
> public class MyPage extends SpecialPage {
>
>
> }
>
> I think this solution is not the best in Tapestry 4.0 but it must work.
> The big problem is that you have to refactor all your existing pages to
> extend SpecialPage.
Read thoroughly (does it spell like that?) the article about hivemind in
'the server side'. There is an example there for just what you are
trying to do.
In Tapestry 4 you use a services layer approach, which, imo, is *much*
better then solving this in the UI layer, like you did in 3. It
seperates concerns and is, in end effect, much better to work with.
>
>
>
> ----- Original Message ----- From: "Ron Piterman" <rp...@gmx.net>
> To: <ta...@jakarta.apache.org>
> Sent: Tuesday, December 13, 2005 1:23 AM
> Subject: Re: Tapestry4 setupForRequest "replacement"?
>
>
>> what about wrapping an object around your initialization and using it
>> in a hivemind threaded model?
>>
>> Ralph Churchill wrote:
>>
>>> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
>>> DataSource from JNDI, open a Connection from it and make the Connection
>>> accessible via static methods to my DAO classes. I closed Connection via
>>> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC
>>> -- no
>>> Hibernate, Spring, etc.
>>>
>>> This simple scheme has worked very well so far.
>>>
>>> I'm looking for an equivalent in Tapestry4. I have seen this sort of
>>> question posed numerous times, but not sufficiently answered. I'm
>>> wondering,
>>> what is the best way to implement functionality similar to this? I
>>> have some
>>> ideas: using RequestGlobals, injecting a service with a "request" or
>>> "thread" scope, etc.
>>>
>>> Please note: for my configuration, a servlet filter is not a viable
>>> option.
>>> Thanks.
>>>
>>> RMC
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is intended only for the
> person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to read, print, retain, copy, disseminate,
> distribute, or use this message or any part thereof. If you receive
> this message in error, please notify the sender immediately and delete
> all copies of this message.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Didier LAFFORGUE <di...@capgemini.com>.
In Tapestry 3.0.3, I had a simple way to get a connection for each request:
all my pages extended a special page (implementing PageRenderListener) which
did some stuffs as: check the if the current user was authentified, ...etc
and open a connection !
The code:
/** The special Page */
public class SpecialPage extends BasePage implements PageValidateListener,
PageRenderListener {
...
public void pageBeginRender(PageEvent event) {
// open a new connection
}
public void pageEndRender(PageEvent event) {
// close the connection
}
}
public class MyPage extends SpecialPage {
}
I think this solution is not the best in Tapestry 4.0 but it must work. The
big problem is that you have to refactor all your existing pages to extend
SpecialPage.
----- Original Message -----
From: "Ron Piterman" <rp...@gmx.net>
To: <ta...@jakarta.apache.org>
Sent: Tuesday, December 13, 2005 1:23 AM
Subject: Re: Tapestry4 setupForRequest "replacement"?
> what about wrapping an object around your initialization and using it in a
> hivemind threaded model?
>
> Ralph Churchill wrote:
>> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
>> DataSource from JNDI, open a Connection from it and make the Connection
>> accessible via static methods to my DAO classes. I closed Connection via
>> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC --
>> no
>> Hibernate, Spring, etc.
>>
>> This simple scheme has worked very well so far.
>>
>> I'm looking for an equivalent in Tapestry4. I have seen this sort of
>> question posed numerous times, but not sufficiently answered. I'm
>> wondering,
>> what is the best way to implement functionality similar to this? I have
>> some
>> ideas: using RequestGlobals, injecting a service with a "request" or
>> "thread" scope, etc.
>>
>> Please note: for my configuration, a servlet filter is not a viable
>> option.
>> Thanks.
>>
>> RMC
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ron Piterman <rp...@gmx.net>.
what about wrapping an object around your initialization and using it in
a hivemind threaded model?
Ralph Churchill wrote:
> In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> DataSource from JNDI, open a Connection from it and make the Connection
> accessible via static methods to my DAO classes. I closed Connection via
> overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC -- no
> Hibernate, Spring, etc.
>
> This simple scheme has worked very well so far.
>
> I'm looking for an equivalent in Tapestry4. I have seen this sort of
> question posed numerous times, but not sufficiently answered. I'm wondering,
> what is the best way to implement functionality similar to this? I have some
> ideas: using RequestGlobals, injecting a service with a "request" or
> "thread" scope, etc.
>
> Please note: for my configuration, a servlet filter is not a viable option.
> Thanks.
>
> RMC
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Tapestry4 setupForRequest "replacement"?
Posted by Ralph Churchill <mr...@gmail.com>.
Unfortunately, my current "platform" is Weblogic 6.1. So, not only am I
stuck using Java 1.3, but also a pre-2.4 servlet engine. Therefore servlet
filters and servlet listeners are not viable :(
What I *think* I'd like to do is something like this:
<service-point id="ConnectionProxy">
<invoke-factory model="threaded">
<construct class="MyConnectionProxy"/>
</invoke-factory>
</service-point>
then...
<service-point id="SomeDAO" >
<construct class="com.foo.SomeDAOImpl">
<set-service id="ConnectionProxy" property="connection" />
</construct>
</service>
But I'm not sure how to "wire" all this up... By the way, I found this
example in the "Injecting registry services to POJOs" thread.**
RMC
On 12/12/05, Bryan Lewis <br...@maine.rr.com> wrote:
>
> I'm dealing with some of the same questions and I'm also feeling
> somewhat under-enlightened by the answers I've gotten, even though I'm
> sure they'll make great sense some day. So the following answer might
> not be the best practice.
>
> I moved my setupForRequest() code to a requestInitialized() method in my
> custom Engine. It gets called at the beginning of each request because I
> registered my Engine class as a ServletRequestListener.
>
> In web.xml:
>
> <listener>
> <listener-class>package.path.Engine</listener-class>
> </listener>
>
> In Engine.java:
>
> public class Engine extends AbstractEngine
> implements ... ServletRequestListener
> {
> ....
> public void requestInitialized(ServletRequestEvent sre) ...
>
>
>
> Ralph Churchill wrote:
>
> >In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
> >DataSource from JNDI, open a Connection from it and make the Connection
> >accessible via static methods to my DAO classes. I closed Connection via
> >overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC --
> no
> >Hibernate, Spring, etc.
> >
> >This simple scheme has worked very well so far.
> >
> >I'm looking for an equivalent in Tapestry4. I have seen this sort of
> >question posed numerous times, but not sufficiently answered. I'm
> wondering,
> >what is the best way to implement functionality similar to this? I have
> some
> >ideas: using RequestGlobals, injecting a service with a "request" or
> >"thread" scope, etc.
> >
> >Please note: for my configuration, a servlet filter is not a viable
> option.
> >Thanks.
> >
> >RMC
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
Re: Tapestry4 setupForRequest "replacement"?
Posted by Bryan Lewis <br...@maine.rr.com>.
I'm dealing with some of the same questions and I'm also feeling
somewhat under-enlightened by the answers I've gotten, even though I'm
sure they'll make great sense some day. So the following answer might
not be the best practice.
I moved my setupForRequest() code to a requestInitialized() method in my
custom Engine. It gets called at the beginning of each request because I
registered my Engine class as a ServletRequestListener.
In web.xml:
<listener>
<listener-class>package.path.Engine</listener-class>
</listener>
In Engine.java:
public class Engine extends AbstractEngine
implements ... ServletRequestListener
{
....
public void requestInitialized(ServletRequestEvent sre) ...
Ralph Churchill wrote:
>In Tapestry3, I overrode BaseEngine's setupForRequest to retrieve a
>DataSource from JNDI, open a Connection from it and make the Connection
>accessible via static methods to my DAO classes. I closed Connection via
>overriding BaseEngine's cleanupAfterRequest. I'm doing straight JDBC -- no
>Hibernate, Spring, etc.
>
>This simple scheme has worked very well so far.
>
>I'm looking for an equivalent in Tapestry4. I have seen this sort of
>question posed numerous times, but not sufficiently answered. I'm wondering,
>what is the best way to implement functionality similar to this? I have some
>ideas: using RequestGlobals, injecting a service with a "request" or
>"thread" scope, etc.
>
>Please note: for my configuration, a servlet filter is not a viable option.
>Thanks.
>
>RMC
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org