You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Roberto Fasciolo <ro...@eget.fi> on 2008/03/02 10:57:36 UTC
Strange thing in Application constructor
Hi,
while trying profiling and debugging our application (which seems to have
some memory leak problems) I've found a strange thing in the constructor of
org.apache.wicket.Application.
When the object is constructed a new component instantiation listener is
created with this code:
// Install default component instantiation listener that uses
// authorization strategy to check component instantiations.
addComponentInstantiationListener(new IComponentInstantiationListener()
{
/**
* @see
org.apache.wicket.application.IComponentInstantiationListener#onInstantiation(org.apache.wicket.Component)
*/
public void onInstantiation(final Component component)
{
// If component instantiation is not authorized
if (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(
component.getClass()))
{
// then call any unauthorized component instantiation
// listener
getSecuritySettings().getUnauthorizedComponentInstantiationListener()
.onUnauthorizedInstantiation(component);
}
}
});
But while having a look at the Session object I've found out that
getAuthorizationStrategy() is calling back Application:
/**
* @return The authorization strategy for this session
*/
public IAuthorizationStrategy getAuthorizationStrategy()
{
return getApplication().getSecuritySettings().getAuthorizationStrategy();
}
I wonder why it has been implemented in that way. Could this statement:
if
(!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
be rewritten as:
if
(!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
??
-Roberto
--
View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15786017.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Maurice Marrink <ma...@gmail.com>.
But in regards to your stateless page problem.
Not only must the page be stateless, but also every component on the
page. A form is not stateless, so you should use a StatelessForm on
your login page.
Also if a RestartResponseAtInterceptPage occurs (which is likely if
you either use wicket-auth-roles or wicket-security) the session must
be made non temporary to store the original page so you can later
return to it.
A couple of ways of avoiding this is to:
- set the login page to the homepage
- make sure all users access the loginpage directly instead of coming
from the homepage (which sees the user needs to authenticate and
throws the exception to redirect to the loginpage)
Maurice
On Wed, Mar 12, 2008 at 12:26 PM, Maurice Marrink <ma...@gmail.com> wrote:
> Its a patch for WicketTester, so not relevant for your situation.
> That's why i asked first instead of blurting out noise like Johan did. :P
>
> Maurice
>
> On Wed, Mar 12, 2008 at 12:11 PM, Roberto Fasciolo
>
> <ro...@eget.fi> wrote:
> >
>
>
> > I'm talking about acceptance tests executed using selenium against the real
> > application (we don't use WicketTester at all).
> >
> > What kind of patch do you have?
> >
> > -Roberto
> >
> >
> >
> > Mr Mean wrote:
> > >
> > > Are you talking about test behavior or real life app behavior?
> > >
> > > Maurice
> > >
> >
> > --
> > View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p16001746.html
> >
> >
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Maurice Marrink <ma...@gmail.com>.
Its a patch for WicketTester, so not relevant for your situation.
That's why i asked first instead of blurting out noise like Johan did. :P
Maurice
On Wed, Mar 12, 2008 at 12:11 PM, Roberto Fasciolo
<ro...@eget.fi> wrote:
>
> I'm talking about acceptance tests executed using selenium against the real
> application (we don't use WicketTester at all).
>
> What kind of patch do you have?
>
> -Roberto
>
>
>
> Mr Mean wrote:
> >
> > Are you talking about test behavior or real life app behavior?
> >
> > Maurice
> >
>
> --
> View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p16001746.html
>
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Roberto Fasciolo <ro...@eget.fi>.
I'm talking about acceptance tests executed using selenium against the real
application (we don't use WicketTester at all).
What kind of patch do you have?
-Roberto
Mr Mean wrote:
>
> Are you talking about test behavior or real life app behavior?
>
> Maurice
>
--
View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p16001746.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Johan Compagner <jc...@gmail.com>.
because maurice has a patch!
On Tue, Mar 11, 2008 at 11:02 AM, Maurice Marrink <ma...@gmail.com> wrote:
> > I've tried setting statelessHint to true in my login page's constructor
> (and
> > in the same constructor printing out the result of isStateless(),
> seeing
> > that it returns true), but still I can see my app's session object
> created
> > and stored in HttpSession (I've tried also with a completely empty
> login
> > page, same result). Am I doing something wrong now?
>
> Are you talking about test behavior or real life app behavior?
>
> Maurice
>
> On Tue, Mar 11, 2008 at 10:20 AM, Roberto Fasciolo
> <ro...@eget.fi> wrote:
> >
> > I finally found some time for getting back to this...
> >
> > The tests are modeled on real user behaviours, so they are not
> invalidating
> > the session because the user has never logged in (we have failing test
> > scenarios for login, registration, forget password and so on).
> >
> > I've tried setting statelessHint to true in my login page's constructor
> (and
> > in the same constructor printing out the result of isStateless(),
> seeing
> > that it returns true), but still I can see my app's session object
> created
> > and stored in HttpSession (I've tried also with a completely empty
> login
> > page, same result). Am I doing something wrong now?
> >
> > -Roberto
> >
> >
> >
> >
> > igor.vaynberg wrote:
> > >
> > > no, its not like that. yes, wicket will create a new session object,
> > > but if the page is stateless that session object is never actually
> > > saved into httpsession...
> > >
> > > you have 20 session active after your tests...do your test cases
> > > always cleanup/invalidate the session? if not then servlet container
> > > will keep the session around until it times out...
> > >
> > > -igor
> > >
> > > On Mon, Mar 3, 2008 at 9:29 AM, Roberto Fasciolo
> > > <ro...@eget.fi> wrote:
> > >>
> > >> I think Session has also the responsibility of verifying if a
> component
> > >> can
> > >> be instantiated.
> > >>
> > >> But anyway, I'm asking all these questions because I'm hunting a
> memory
> > >> leak
> > >> in my application and I've found that after running a 120+ tests
> > >> selenium
> > >> test suite I've 20+ sessions still in memory retained by Jetty (e.g
> .
> > >> active
> > >> sessions in the web container) and I'm wondering if that's a
> problem or
> > >> not.
> > >> I've understood now that I have no way to control that, everytime a
> user
> > >> opens a page in a wicket app a new Session is created just for
> checking
> > >> if
> > >> that user can instantiate components, regardless of wether the page
> is
> > >> stateless or stateful and also if the user has never signed in the
> site.
> > >> Is
> > >> it like that?
> > >>
> > >> -Roberto
> > >>
> > >>
> > >>
> > >> igor.vaynberg wrote:
> > >> >
> > >> > session represents a user's session, while application represents
> the
> > >> > application that users access.
> > >> >
> > >> > -igor
> > >> >
> > >>
> > >> --
> > >> View this message in context:
> > >>
> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
> > >>
> > >>
> > >> Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
> > >>
> > >>
> > >>
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15975715.html
> >
> >
> > Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Strange thing in Application constructor
Posted by Maurice Marrink <ma...@gmail.com>.
> I've tried setting statelessHint to true in my login page's constructor (and
> in the same constructor printing out the result of isStateless(), seeing
> that it returns true), but still I can see my app's session object created
> and stored in HttpSession (I've tried also with a completely empty login
> page, same result). Am I doing something wrong now?
Are you talking about test behavior or real life app behavior?
Maurice
On Tue, Mar 11, 2008 at 10:20 AM, Roberto Fasciolo
<ro...@eget.fi> wrote:
>
> I finally found some time for getting back to this...
>
> The tests are modeled on real user behaviours, so they are not invalidating
> the session because the user has never logged in (we have failing test
> scenarios for login, registration, forget password and so on).
>
> I've tried setting statelessHint to true in my login page's constructor (and
> in the same constructor printing out the result of isStateless(), seeing
> that it returns true), but still I can see my app's session object created
> and stored in HttpSession (I've tried also with a completely empty login
> page, same result). Am I doing something wrong now?
>
> -Roberto
>
>
>
>
> igor.vaynberg wrote:
> >
> > no, its not like that. yes, wicket will create a new session object,
> > but if the page is stateless that session object is never actually
> > saved into httpsession...
> >
> > you have 20 session active after your tests...do your test cases
> > always cleanup/invalidate the session? if not then servlet container
> > will keep the session around until it times out...
> >
> > -igor
> >
> > On Mon, Mar 3, 2008 at 9:29 AM, Roberto Fasciolo
> > <ro...@eget.fi> wrote:
> >>
> >> I think Session has also the responsibility of verifying if a component
> >> can
> >> be instantiated.
> >>
> >> But anyway, I'm asking all these questions because I'm hunting a memory
> >> leak
> >> in my application and I've found that after running a 120+ tests
> >> selenium
> >> test suite I've 20+ sessions still in memory retained by Jetty (e.g.
> >> active
> >> sessions in the web container) and I'm wondering if that's a problem or
> >> not.
> >> I've understood now that I have no way to control that, everytime a user
> >> opens a page in a wicket app a new Session is created just for checking
> >> if
> >> that user can instantiate components, regardless of wether the page is
> >> stateless or stateful and also if the user has never signed in the site.
> >> Is
> >> it like that?
> >>
> >> -Roberto
> >>
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > session represents a user's session, while application represents the
> >> > application that users access.
> >> >
> >> > -igor
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
> >>
> >>
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15975715.html
>
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Roberto Fasciolo <ro...@eget.fi>.
I finally found some time for getting back to this...
The tests are modeled on real user behaviours, so they are not invalidating
the session because the user has never logged in (we have failing test
scenarios for login, registration, forget password and so on).
I've tried setting statelessHint to true in my login page's constructor (and
in the same constructor printing out the result of isStateless(), seeing
that it returns true), but still I can see my app's session object created
and stored in HttpSession (I've tried also with a completely empty login
page, same result). Am I doing something wrong now?
-Roberto
igor.vaynberg wrote:
>
> no, its not like that. yes, wicket will create a new session object,
> but if the page is stateless that session object is never actually
> saved into httpsession...
>
> you have 20 session active after your tests...do your test cases
> always cleanup/invalidate the session? if not then servlet container
> will keep the session around until it times out...
>
> -igor
>
> On Mon, Mar 3, 2008 at 9:29 AM, Roberto Fasciolo
> <ro...@eget.fi> wrote:
>>
>> I think Session has also the responsibility of verifying if a component
>> can
>> be instantiated.
>>
>> But anyway, I'm asking all these questions because I'm hunting a memory
>> leak
>> in my application and I've found that after running a 120+ tests
>> selenium
>> test suite I've 20+ sessions still in memory retained by Jetty (e.g.
>> active
>> sessions in the web container) and I'm wondering if that's a problem or
>> not.
>> I've understood now that I have no way to control that, everytime a user
>> opens a page in a wicket app a new Session is created just for checking
>> if
>> that user can instantiate components, regardless of wether the page is
>> stateless or stateful and also if the user has never signed in the site.
>> Is
>> it like that?
>>
>> -Roberto
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > session represents a user's session, while application represents the
>> > application that users access.
>> >
>> > -igor
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
>>
>>
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15975715.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Igor Vaynberg <ig...@gmail.com>.
no, its not like that. yes, wicket will create a new session object,
but if the page is stateless that session object is never actually
saved into httpsession...
you have 20 session active after your tests...do your test cases
always cleanup/invalidate the session? if not then servlet container
will keep the session around until it times out...
-igor
On Mon, Mar 3, 2008 at 9:29 AM, Roberto Fasciolo
<ro...@eget.fi> wrote:
>
> I think Session has also the responsibility of verifying if a component can
> be instantiated.
>
> But anyway, I'm asking all these questions because I'm hunting a memory leak
> in my application and I've found that after running a 120+ tests selenium
> test suite I've 20+ sessions still in memory retained by Jetty (e.g. active
> sessions in the web container) and I'm wondering if that's a problem or not.
> I've understood now that I have no way to control that, everytime a user
> opens a page in a wicket app a new Session is created just for checking if
> that user can instantiate components, regardless of wether the page is
> stateless or stateful and also if the user has never signed in the site. Is
> it like that?
>
> -Roberto
>
>
>
> igor.vaynberg wrote:
> >
> > session represents a user's session, while application represents the
> > application that users access.
> >
> > -igor
> >
>
> --
> View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
>
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Roberto Fasciolo <ro...@eget.fi>.
I think Session has also the responsibility of verifying if a component can
be instantiated.
But anyway, I'm asking all these questions because I'm hunting a memory leak
in my application and I've found that after running a 120+ tests selenium
test suite I've 20+ sessions still in memory retained by Jetty (e.g. active
sessions in the web container) and I'm wondering if that's a problem or not.
I've understood now that I have no way to control that, everytime a user
opens a page in a wicket app a new Session is created just for checking if
that user can instantiate components, regardless of wether the page is
stateless or stateful and also if the user has never signed in the site. Is
it like that?
-Roberto
igor.vaynberg wrote:
>
> session represents a user's session, while application represents the
> application that users access.
>
> -igor
>
--
View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Igor Vaynberg <ig...@gmail.com>.
session represents a user's session, while application represents the
application that users access.
-igor
On Sun, Mar 2, 2008 at 11:03 PM, Roberto Fasciolo
<ro...@eget.fi> wrote:
>
> So, what are the responsibilities of the class org.apache.wicket.Session and
> what's the contract between Session and org.apache.wicket.Application?
>
> I'm asking because to me both them are a bit unclear (and the javadocs can't
> help me in understand them at all).
>
> -Roberto
>
>
>
>
> igor.vaynberg wrote:
> >
> > it is that way so you can have a different auth strategy per session
> > by overriding sesssion.getauthstrat()
> >
> > -igor
> >
> >
> > On Sun, Mar 2, 2008 at 1:57 AM, Roberto Fasciolo
> > <ro...@eget.fi> wrote:
> >>
> >> Hi,
> >>
> >> while trying profiling and debugging our application (which seems to
> >> have
> >> some memory leak problems) I've found a strange thing in the constructor
> >> of
> >> org.apache.wicket.Application.
> >>
> >> When the object is constructed a new component instantiation listener is
> >> created with this code:
> >>
> >> // Install default component instantiation listener that
> >> uses
> >> // authorization strategy to check component
> >> instantiations.
> >> addComponentInstantiationListener(new
> >> IComponentInstantiationListener()
> >> {
> >> /**
> >> * @see
> >>
> >> org.apache.wicket.application.IComponentInstantiationListener#onInstantiation(org.apache.wicket.Component)
> >> */
> >> public void onInstantiation(final Component
> >> component)
> >> {
> >> // If component instantiation is not
> >> authorized
> >> if
> >> (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(
> >> component.getClass()))
> >> {
> >> // then call any unauthorized
> >> component instantiation
> >> // listener
> >>
> >> getSecuritySettings().getUnauthorizedComponentInstantiationListener()
> >>
> >> .onUnauthorizedInstantiation(component);
> >> }
> >> }
> >> });
> >>
> >>
> >> But while having a look at the Session object I've found out that
> >> getAuthorizationStrategy() is calling back Application:
> >>
> >> /**
> >> * @return The authorization strategy for this session
> >> */
> >> public IAuthorizationStrategy getAuthorizationStrategy()
> >> {
> >> return
> >> getApplication().getSecuritySettings().getAuthorizationStrategy();
> >> }
> >>
> >>
> >> I wonder why it has been implemented in that way. Could this statement:
> >>
> >> if
> >>
> >> (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
> >>
> >> be rewritten as:
> >>
> >> if
> >>
> >> (!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
> >>
> >> ??
> >>
> >> -Roberto
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15786017.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15798693.html
>
>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Roberto Fasciolo <ro...@eget.fi>.
So, what are the responsibilities of the class org.apache.wicket.Session and
what's the contract between Session and org.apache.wicket.Application?
I'm asking because to me both them are a bit unclear (and the javadocs can't
help me in understand them at all).
-Roberto
igor.vaynberg wrote:
>
> it is that way so you can have a different auth strategy per session
> by overriding sesssion.getauthstrat()
>
> -igor
>
>
> On Sun, Mar 2, 2008 at 1:57 AM, Roberto Fasciolo
> <ro...@eget.fi> wrote:
>>
>> Hi,
>>
>> while trying profiling and debugging our application (which seems to
>> have
>> some memory leak problems) I've found a strange thing in the constructor
>> of
>> org.apache.wicket.Application.
>>
>> When the object is constructed a new component instantiation listener is
>> created with this code:
>>
>> // Install default component instantiation listener that
>> uses
>> // authorization strategy to check component
>> instantiations.
>> addComponentInstantiationListener(new
>> IComponentInstantiationListener()
>> {
>> /**
>> * @see
>>
>> org.apache.wicket.application.IComponentInstantiationListener#onInstantiation(org.apache.wicket.Component)
>> */
>> public void onInstantiation(final Component
>> component)
>> {
>> // If component instantiation is not
>> authorized
>> if
>> (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(
>> component.getClass()))
>> {
>> // then call any unauthorized
>> component instantiation
>> // listener
>>
>> getSecuritySettings().getUnauthorizedComponentInstantiationListener()
>>
>> .onUnauthorizedInstantiation(component);
>> }
>> }
>> });
>>
>>
>> But while having a look at the Session object I've found out that
>> getAuthorizationStrategy() is calling back Application:
>>
>> /**
>> * @return The authorization strategy for this session
>> */
>> public IAuthorizationStrategy getAuthorizationStrategy()
>> {
>> return
>> getApplication().getSecuritySettings().getAuthorizationStrategy();
>> }
>>
>>
>> I wonder why it has been implemented in that way. Could this statement:
>>
>> if
>>
>> (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
>>
>> be rewritten as:
>>
>> if
>>
>> (!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
>>
>> ??
>>
>> -Roberto
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15786017.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15798693.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Maurice Marrink <ma...@gmail.com>.
Swarm for instances uses the "strategy per session" technique to also
store the user credentials in the strategy.
Maurice
On Sun, Mar 2, 2008 at 6:25 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> it is that way so you can have a different auth strategy per session
> by overriding sesssion.getauthstrat()
>
> -igor
>
>
>
>
> On Sun, Mar 2, 2008 at 1:57 AM, Roberto Fasciolo
> <ro...@eget.fi> wrote:
> >
> > Hi,
> >
> > while trying profiling and debugging our application (which seems to have
> > some memory leak problems) I've found a strange thing in the constructor of
> > org.apache.wicket.Application.
> >
> > When the object is constructed a new component instantiation listener is
> > created with this code:
> >
> > // Install default component instantiation listener that uses
> > // authorization strategy to check component instantiations.
> > addComponentInstantiationListener(new IComponentInstantiationListener()
> > {
> > /**
> > * @see
> > org.apache.wicket.application.IComponentInstantiationListener#onInstantiation(org.apache.wicket.Component)
> > */
> > public void onInstantiation(final Component component)
> > {
> > // If component instantiation is not authorized
> > if (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(
> > component.getClass()))
> > {
> > // then call any unauthorized component instantiation
> > // listener
> > getSecuritySettings().getUnauthorizedComponentInstantiationListener()
> > .onUnauthorizedInstantiation(component);
> > }
> > }
> > });
> >
> >
> > But while having a look at the Session object I've found out that
> > getAuthorizationStrategy() is calling back Application:
> >
> > /**
> > * @return The authorization strategy for this session
> > */
> > public IAuthorizationStrategy getAuthorizationStrategy()
> > {
> > return getApplication().getSecuritySettings().getAuthorizationStrategy();
> > }
> >
> >
> > I wonder why it has been implemented in that way. Could this statement:
> >
> > if
> > (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
> >
> > be rewritten as:
> >
> > if
> > (!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
> >
> > ??
> >
> > -Roberto
> >
> >
> >
> > --
> > View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15786017.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange thing in Application constructor
Posted by Igor Vaynberg <ig...@gmail.com>.
it is that way so you can have a different auth strategy per session
by overriding sesssion.getauthstrat()
-igor
On Sun, Mar 2, 2008 at 1:57 AM, Roberto Fasciolo
<ro...@eget.fi> wrote:
>
> Hi,
>
> while trying profiling and debugging our application (which seems to have
> some memory leak problems) I've found a strange thing in the constructor of
> org.apache.wicket.Application.
>
> When the object is constructed a new component instantiation listener is
> created with this code:
>
> // Install default component instantiation listener that uses
> // authorization strategy to check component instantiations.
> addComponentInstantiationListener(new IComponentInstantiationListener()
> {
> /**
> * @see
> org.apache.wicket.application.IComponentInstantiationListener#onInstantiation(org.apache.wicket.Component)
> */
> public void onInstantiation(final Component component)
> {
> // If component instantiation is not authorized
> if (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(
> component.getClass()))
> {
> // then call any unauthorized component instantiation
> // listener
> getSecuritySettings().getUnauthorizedComponentInstantiationListener()
> .onUnauthorizedInstantiation(component);
> }
> }
> });
>
>
> But while having a look at the Session object I've found out that
> getAuthorizationStrategy() is calling back Application:
>
> /**
> * @return The authorization strategy for this session
> */
> public IAuthorizationStrategy getAuthorizationStrategy()
> {
> return getApplication().getSecuritySettings().getAuthorizationStrategy();
> }
>
>
> I wonder why it has been implemented in that way. Could this statement:
>
> if
> (!Session.get().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
>
> be rewritten as:
>
> if
> (!getSecuritySettings().getAuthorizationStrategy().isInstantiationAuthorized(component.getClass()))
>
> ??
>
> -Roberto
>
>
>
> --
> View this message in context: http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15786017.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org