Re: Strange thing in Application constructor

[Maurice Marrink]

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 <[EMAIL PROTECTED]> 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
>
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Maurice Marrink]

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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Roberto Fasciolo]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Johan Compagner]

because maurice has a patch!

On Tue, Mar 11, 2008 at 11:02 AM, Maurice Marrink <[EMAIL PROTECTED]> 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
>  <[EMAIL PROTECTED]> 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
> >  > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> >  >>  For additional commands, e-mail: [EMAIL PROTECTED]
> >  >>
> >  >>
> >  >
> >  > -
> >  > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  > For additional commands, e-mail: [EMAIL PROTECTED]
> >  >
> >  >
> >  >
> >
> >  --
> >  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: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Strange thing in Application constructor

[Maurice Marrink]

>  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
<[EMAIL PROTECTED]> 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
>  > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  >>  For additional commands, e-mail: [EMAIL PROTECTED]
>  >>
>  >>
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>  >
>
>  --
>  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: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Roberto Fasciolo]

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
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>  For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Igor Vaynberg]

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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Roberto Fasciolo]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Igor Vaynberg]

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
<[EMAIL PROTECTED]> 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
>  > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  >>  For additional commands, e-mail: [EMAIL PROTECTED]
>  >>
>  >>
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>  >
>
>  --
>  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: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Roberto Fasciolo]

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
> <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>  For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Maurice Marrink]

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 <[EMAIL PROTECTED]> 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
>  <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  >  For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Strange thing in Application constructor

[Igor Vaynberg]

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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]