You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by di...@bgs-ag.de on 2009/10/01 15:15:37 UTC
Instantiation of perthread dispatcher
Hello list!
I'm using the HOWTO at the tapestry5 wiki (unaccessible right now)
for access control to my pages and implemented a dispatcher.
I used in my AppModule
----------
public static void bind(ServiceBinder binder)
{
binder.bind(OssoAccessController.class);
}
public static void
contributeMasterDispatcher(OrderedConfiguration<Dispatcher> configuration,
OssoAccessController accessController) {
configuration.add("AccessController", accessController,
"before:PageRender");
}
----------
As I'm using SSO (single sign on), the login page is external to my
application, and the login state could change without the application
knowing. The login state can be read via a request attribute. So, in my
dispatcher, I determine which user is logged on by examining the request
attribute and write the information into the session (session state
object). This means the dispatcher has to be:
@Scope( ScopeConstants.PERTHREAD)
class OssoAccessControllerImpl {...}
Everything seems to work well, but when I looked at the log, I was
shocked:
----------------------------------
2009-10-01 11:07:39,761 [http-8080-4] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,763 [http-8080-1] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,767 [http-8080-1] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,779 [http-8080-1] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,782 [http-8080-4] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,787 [http-8080-1] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,791 [http-8080-4] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
2009-10-01 11:07:39,797 [http-8080-1] DEBUG
xxx.services.AppModule.OssoAccessController - Invoking constructor
xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
OssoAccessControllerImpl.java:35) via
xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
----------------------------------
This is just for the render part request after the tapestry redirect! When
exactly is the dispatcher instantiated? I thought it would be once for
each request, not eight times. It's also strange to see two different
thread names in the log (not one, not eight). Is the dispatcher somehow
instantiated once per page and component?
Is there something wrong with "before:PageRender"?
Thank you,
Dirk
BGS Beratungsgesellschaft
Software Systemplanung AG Niederlassung Köln/Bonn
Grantham-Allee 2-8
53757 Sankt Augustin
Fon: +49 (0) 2241 / 166-500
Fax: +49 (0) 2241 / 166-680
www.bgs-ag.de Geschäftssitz Mainz
Registergericht
Amtsgericht Mainz
HRB 62 50
Aufsichtsratsvorsitzender
Klaus Hellwig
Vorstand
Hermann Kiefer
Nils Manegold
Thomas Reitz
Antwort: Re: Antwort: Re: Instantiation of perthread dispatcher
Posted by di...@bgs-ag.de.
"Thiago H. de Paula Figueiredo" <th...@gmail.com> schrieb am 01.10.2009
16:28:07:
> > The OssoAccessControllerImpl gets some authentication info from the
> > request and creates a User object.
> > I want(ed) to store this object into the session, so I need an
> > ApplicationStateManager, because the @Session annotation can't be used
> > here (we're in a service). The ApplicationStateManager can be injected
> > into the OssoAccessControllerImpl constructor, so the latter must be
> > request specifice, i.e. per thread.
>
> It still doesn't need to be per thread. You can even inject Request or
> HttpServletRequest in a singleton service and you still get the right
> instance when you invoke some method on them. The instance that is
> injected is a proxy, not the real object, and this proxy delegates the
> method calls to the correct instance for that given thread.
>
Well, this is starting to be much fun! I think I tried @Session which
didn't work in the service, but I might get away with injecting the
ApplicationStateManager! Will try that next.
> > I'm still astonished there are so many of them.
>
> How many assets do you have in your page? I guess it's 7. :)
Will need some quiet minutes to do the counting... :)
Dirk
BGS Beratungsgesellschaft
Software Systemplanung AG Niederlassung Köln/Bonn
Grantham-Allee 2-8
53757 Sankt Augustin
Fon: +49 (0) 2241 / 166-500
Fax: +49 (0) 2241 / 166-680
www.bgs-ag.de Geschäftssitz Mainz
Registergericht
Amtsgericht Mainz
HRB 62 50
Aufsichtsratsvorsitzender
Klaus Hellwig
Vorstand
Hermann Kiefer
Nils Manegold
Thomas Reitz
Re: Antwort: Re: Instantiation of perthread dispatcher
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 01 Oct 2009 11:16:15 -0300, <di...@bgs-ag.de> escreveu:
> The OssoAccessControllerImpl gets some authentication info from the
> request and creates a User object.
> I want(ed) to store this object into the session, so I need an
> ApplicationStateManager, because the @Session annotation can't be used
> here (we're in a service). The ApplicationStateManager can be injected
> into the OssoAccessControllerImpl constructor, so the latter must be
> request specifice, i.e. per thread.
It still doesn't need to be per thread. You can even inject Request or
HttpServletRequest in a singleton service and you still get the right
instance when you invoke some method on them. The instance that is
injected is a proxy, not the real object, and this proxy delegates the
method calls to the correct instance for that given thread.
> However, your comment made it clear to me that I could put the User
> object into the request instead of into the session. Then, I can fetch
> it via the Request service which can be injected wherever I would have
> used @Session
> private User user; ! This is much better! Thanks!
You're welcome!
> I'm still astonished there are so many of them.
How many assets do you have in your page? I guess it's 7. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Antwort: Re: Instantiation of perthread dispatcher
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 01 Oct 2009 11:33:33 -0300, <di...@bgs-ag.de> escreveu:
> Well, on second thought, it isn't really better as creating the User
> object involves LDAP access, thus some overhead. I'd prefer creating the
> User object only if the authorization info has changed since the last
> request. This would require storing it into the session, and the access
> controller needs to be perthread. Is this correct after all?
Yes, but the controller doesn't need to be perthread. Believe me. :) Or at
least try it. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Antwort: Re: Instantiation of perthread dispatcher
Posted by di...@bgs-ag.de.
Dirk Lattermann/bn/bgs-ag/de schrieb am 01.10.2009 16:16:15:
> "Thiago H. de Paula Figueiredo" <th...@gmail.com> schrieb am 01.10.
> > > @Scope( ScopeConstants.PERTHREAD)
> > > class OssoAccessControllerImpl {...}
> >
> > I can't see why it should be per thread.
>
> The OssoAccessControllerImpl gets some authentication info from the
> request and creates a User object.
> I want(ed) to store this object into the session, so I need an
> ApplicationStateManager, because the @Session annotation can't be used
> here (we're in a service). The ApplicationStateManager can be injected
> into the OssoAccessControllerImpl constructor, so the latter must be
> request specifice, i.e. per thread.
>
> However, your comment made it clear to me that I could put the User
> object into the request instead of into the session. Then, I can fetch
> it via the Request service which can be injected wherever I would have
> used @Session private User user; ! This is much better! Thanks!
Well, on second thought, it isn't really better as creating the User
object involves LDAP access, thus some overhead. I'd prefer creating the
User object only if the authorization info has changed since the last
request. This would require storing it into the session, and the access
controller needs to be perthread. Is this correct after all?
Dirk
BGS Beratungsgesellschaft
Software Systemplanung AG Niederlassung Köln/Bonn
Grantham-Allee 2-8
53757 Sankt Augustin
Fon: +49 (0) 2241 / 166-500
Fax: +49 (0) 2241 / 166-680
www.bgs-ag.de Geschäftssitz Mainz
Registergericht
Amtsgericht Mainz
HRB 62 50
Aufsichtsratsvorsitzender
Klaus Hellwig
Vorstand
Hermann Kiefer
Nils Manegold
Thomas Reitz
Antwort: Re: Instantiation of perthread dispatcher
Posted by di...@bgs-ag.de.
"Thiago H. de Paula Figueiredo" <th...@gmail.com> schrieb am 01.10.2009
15:52:51:
>
> > @Scope( ScopeConstants.PERTHREAD)
> > class OssoAccessControllerImpl {...}
>
> I can't see why it should be per thread.
The OssoAccessControllerImpl gets some authentication info from the
request and creates a User object.
I want(ed) to store this object into the session, so I need an
ApplicationStateManager, because the @Session annotation can't be used
here (we're in a service). The ApplicationStateManager can be injected
into the OssoAccessControllerImpl constructor, so the latter must be
request specifice, i.e. per thread.
However, your comment made it clear to me that I could put the User object
into the request instead of into the session. Then, I can fetch it via the
Request service which can be injected wherever I would have used @Session
private User user; ! This is much better! Thanks!
>
> Requests for assets (CSS, JavaScript, etc) are requests too.
>
I'm still astonished there are so many of them.
Dirk
BGS Beratungsgesellschaft
Software Systemplanung AG
Niederlassung Köln/Bonn
Grantham-Allee 2-8
53757 Sankt Augustin
Fon: +49 (0) 2241 / 166-500
Fax: +49 (0) 2241 / 166-680
www.bgs-ag.de
Geschäftssitz Mainz
Registergericht
Amtsgericht Mainz
HRB 62 50
Aufsichtsratsvorsitzender
Klaus Hellwig
Vorstand
Hermann Kiefer
Nils Manegold
Thomas Reitz
Re: Instantiation of perthread dispatcher
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 01 Oct 2009 10:15:37 -0300, <di...@bgs-ag.de> escreveu:
> Hello list!
Hi!
> @Scope( ScopeConstants.PERTHREAD)
> class OssoAccessControllerImpl {...}
I can't see why it should be per thread.
> This is just for the render part request after the tapestry redirect!
> When exactly is the dispatcher instantiated?
Once per thread, i.e. once per request.
> I thought it would be once for
> each request, not eight times.
Requests for assets (CSS, JavaScript, etc) are requests too.
> It's also strange to see two different
> thread names in the log (not one, not eight). Is the dispatcher somehow
> instantiated once per page and component?
No. It is instantiated once per thread. :)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Instantiation of perthread dispatcher
Posted by cordenier christophe <ch...@gmail.com>.
Sorry, you're right. I said something wrong :)
2009/10/1 Thiago H. de Paula Figueiredo <th...@gmail.com>
> Em Thu, 01 Oct 2009 10:21:10 -0300, cordenier christophe <
> christophe.cordenier@gmail.com> escreveu:
>
> Why not using a ComponentRequestFilter or even a RequestFilter ? This is
>> perthread by default.
>>
>
> They're singletons, not being instantiated per thread.
>
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Instantiation of perthread dispatcher
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 01 Oct 2009 10:21:10 -0300, cordenier christophe
<ch...@gmail.com> escreveu:
> Why not using a ComponentRequestFilter or even a RequestFilter ? This is
> perthread by default.
They're singletons, not being instantiated per thread.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Instantiation of perthread dispatcher
Posted by cordenier christophe <ch...@gmail.com>.
Hello
Why not using a ComponentRequestFilter or even a RequestFilter ? This is
perthread by default.
2009/10/1 <di...@bgs-ag.de>
> Hello list!
>
> I'm using the HOWTO at the tapestry5 wiki (unaccessible right now)
> for access control to my pages and implemented a dispatcher.
>
> I used in my AppModule
>
> ----------
> public static void bind(ServiceBinder binder)
> {
> binder.bind(OssoAccessController.class);
> }
>
> public static void
> contributeMasterDispatcher(OrderedConfiguration<Dispatcher> configuration,
> OssoAccessController accessController) {
> configuration.add("AccessController", accessController,
> "before:PageRender");
> }
> ----------
>
> As I'm using SSO (single sign on), the login page is external to my
> application, and the login state could change without the application
> knowing. The login state can be read via a request attribute. So, in my
> dispatcher, I determine which user is logged on by examining the request
> attribute and write the information into the session (session state
> object). This means the dispatcher has to be:
>
> @Scope( ScopeConstants.PERTHREAD)
> class OssoAccessControllerImpl {...}
>
> Everything seems to work well, but when I looked at the log, I was
> shocked:
>
> ----------------------------------
> 2009-10-01 11:07:39,761 [http-8080-4] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,763 [http-8080-1] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,767 [http-8080-1] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,779 [http-8080-1] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,782 [http-8080-4] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,787 [http-8080-1] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,791 [http-8080-4] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> 2009-10-01 11:07:39,797 [http-8080-1] DEBUG
> xxx.services.AppModule.OssoAccessController - Invoking constructor
> xxx.services.OssoAccessControllerImpl(ApplicationStateManager,
> ComponentClassResolver, ComponentSource, ConfigProperties, Logger) (at
> OssoAccessControllerImpl.java:35) via
> xxx.services.AppModule.bind(ServiceBinder) (at AppModule.java:31).
> ----------------------------------
>
> This is just for the render part request after the tapestry redirect! When
> exactly is the dispatcher instantiated? I thought it would be once for
> each request, not eight times. It's also strange to see two different
> thread names in the log (not one, not eight). Is the dispatcher somehow
> instantiated once per page and component?
>
> Is there something wrong with "before:PageRender"?
>
> Thank you,
> Dirk
> BGS Beratungsgesellschaft
> Software Systemplanung AG Niederlassung Köln/Bonn
> Grantham-Allee 2-8
> 53757 Sankt Augustin
> Fon: +49 (0) 2241 / 166-500
> Fax: +49 (0) 2241 / 166-680
> www.bgs-ag.de Geschäftssitz Mainz
> Registergericht
> Amtsgericht Mainz
> HRB 62 50
> Aufsichtsratsvorsitzender
> Klaus Hellwig
> Vorstand
> Hermann Kiefer
> Nils Manegold
> Thomas Reitz
>
>